Aalto University
School of Science
Degree Programme in Computer Science and Engineering
Vittorio Dal Bianco
Third-Party Developer Experience:
Using the platform boundary resources of a
software ecosystem
Master’s Thesis
Espoo, August 16, 2013
Supervisor:
Professor Marjo Kauppinen, Aalto University
Advisor:
Mikko Raatikainen M.Sc. (Tech.)
Aalto University
School of Science
Degree Programme in Computer Science and Engineering
ABSTRACT OF
MASTER’S THESIS
Author:
Vittorio Dal Bianco
Title:
Third-Party Developer Experience: Using the platform boundary resources of a
software ecosystem
Date:
August 16, 2013
Pages: ix + 90
Major:
Software Engineering
Code: T-76
Supervisor:
Professor Marjo Kauppinen
Advisor:
Mikko Raatikainen M.Sc. (Tech.)
Software ecosystems are an increasingly common setting in which software organizations operate. A software ecosystem refers to a context where a keystone
player, or platform owner, provides a software platform and platform boundary
resources. These resources allow third-party developers to build software applications on top of the platform. These applications target end-users who selected to
adopt the software platform. The relationships among the entities we introduced
are the engine of a software ecosystem.
After selecting the software platform, much of the interaction the end-users have
with the software ecosystem happens by selecting and using the software applications that are available in the software ecosystem. Hence, software applications
play a crucial role in the success of the software ecosystem. Attracting third-party
developers to build software applications is, therefore, a key issue.
In this sense, a fundamental technical concern is third-party developer experience.
In fact, minimizing developers effort is recognized as one of the key success factors;
and it requires acting on the platform boundary resources. We understand this
as enabling third-party development.
We investigated these issues in the specific context of F-Secure’s Content Anywhere (CAN) Ecosystem. We conducted a case study in a hackathon event, where
F-Secure used the CAN Ecosystem.
We found out that enablement can occur to different degrees. We concluded that
the minimum requirement is to ensure technical feasibility through APIs and
access to basic resources. While, for example, addressing issues of learnability
and abstraction levels helps to raise the degree of enablement; thus increasing
the software ecosystem’s attractiveness to third-party developers. Additionally,
the third-party developer experience is affected by met or unmet expectations;
the expectations depend on the mental model that the developer constructs.
Keywords:
software ecosystems, third-party developer experience, platform boundary resources
Language:
English
ii
Acknowledgements
I wish to thank all the people that, in different ways, have supported me
throughout my master’s thesis journey and during my master’s at Aalto
University.
First of all, special thanks to my instructor Mikko Raatikainen for the
precious feedback, support and guidance that he has constantly given me.
Thanks for reviewing this thesis a number of times and helping me to steer it
to the right direction. Another special thanks to my supervisor Marjo Kauppinen, for the guidance she offered and for the continuous encouragements. I
would also want to thank Tömi Männistö for supervising this research work
at the beginning of its journey.
My gratitude also goes to Danielle Pichlis, Jari Pääkkö and Mikko Ylikangas. Thanks for all the advices and practical help, but most of all thanks
for sharing all the moments that have led to the completion of this master’s thesis. In addition, I would like to thank all the other people from the
Preago research group. I am also thankful to SoberIT for the giving me the
opportunity to work on my master’s thesis.
I also want to thank Marko Komssi, Janne Järvinen, Klas Kindström,
Heikki Nousiainen and all the other people at F-Secure that made this research work possible. I would like thank this people also for the article we
wrote, together with Mikko Raatikainen, for COMPSAC ’13.
I also wish to thank the SMT 10 A crew: Simon, Raisa, Marc and
Danielle. Thanks for the great time we had together, for believing in me
and bringing joy in this journey.
Finally I want to thank my family for supporting me during the studies
in Finland, and also before. Thanks for the countless Skype calls and the
nice moments spent together.
Espoo, August 16, 2013
Vittorio Dal Bianco
iii
“Sit down before fact with an open mind. Be prepared to give
up every preconceived notion. Follow humbly wherever and to
whatever abyss Nature leads or you learn nothing. Don’t push
out figures when facts are going in the opposite direction.”
–Admiral Hyman G. Rickover
“Technology makes it possible for people to gain control over
everything, except over technology.”
–Jhon Tudor
“It troubles me that we are so easily pressured by purveyors of
technology into permitting so-called “progress” to alter our lives
without attempting to control it’as if technology were an irrepressible force of nature to which we must meekly submit.”
–Admiral Hyman G. Rickover
iv
Contents
1 Introduction
1.1 Background . . . . . . . . . . .
1.2 Problem Area . . . . . . . . . .
1.3 Research Problem . . . . . . . .
1.4 Hackathon . . . . . . . . . . . .
1.4.1 Hackathons’ Description
1.4.2 Hackathon Activities . .
1.5 Scope of the Thesis . . . . . . .
1.6 Thesis Outline . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2 Research Method
2.1 Empirical Data Collection . . . . . . . .
2.1.1 In the Hackathon . . . . . . . . .
2.1.2 Interviews and Feedback Meeting
2.2 Data Analysis . . . . . . . . . . . . . . .
3 Software Ecosystems
3.1 Definition of Software Ecosystems .
3.2 Software platforms in SECOs . . .
3.3 A Theory of Software Ecosystems .
3.4 Taxonomy of Software Ecosystems .
3.5 Roles in Software Ecosystems . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4 Third-Party Development
in SECOs
4.1 Software Platforms . . . . . . . . . . . . . . . . . . . . . . .
4.1.1 Software Platforms Architecture . . . . . . . . . . . .
4.1.2 Platform Boundary Resources and Third-party Development . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Platform Boundary Resources . . . . . . . . . . . . . . . . .
4.3 Boundary Objects in Design . . . . . . . . . . . . . . . . . .
v
.
.
.
.
.
.
.
.
1
1
4
5
8
8
9
10
10
.
.
.
.
12
12
14
16
19
.
.
.
.
.
21
22
24
26
29
32
36
. 36
. 37
. 38
. 40
. 42
5 Third-Party Developer Experience
5.1 Quality Characteristics and Quality in Use (ISO/IEC 9126-1)
5.1.1 Relation to Third-Party Developer Experience . . . . .
5.1.2 Metrics from Software Quality . . . . . . . . . . . . . .
5.2 Usability (ISO 9241-11) . . . . . . . . . . . . . . . . . . . . .
5.2.1 Relation to Third-Party Developer Experience . . . . .
5.2.2 Metrics from Usability . . . . . . . . . . . . . . . . . .
5.3 User Experience (ISO 9241-210) . . . . . . . . . . . . . . . . .
5.3.1 Relation to Third-Party Developer Experience . . . . .
5.3.2 Metrics from User Experience . . . . . . . . . . . . . .
5.4 The Standards and Third-party Developer Experience . . . . .
45
46
46
49
50
50
51
53
53
54
55
6 Results of the Case Study
6.1 CAN Ecosystem . . . . . . . . . . . . . . . . . . .
6.1.1 Software Platform Architecture . . . . . .
6.1.2 Platform Boundary Resources . . . . . . .
6.1.3 Technical Platform Boundary Resources .
6.1.4 Social Platform Boundary Resources . . .
6.2 Evaluation . . . . . . . . . . . . . . . . . . . . . .
6.2.1 Understanding the Platform Architecture .
6.2.2 Learnability . . . . . . . . . . . . . . . . .
6.2.3 Developer Portal and Registration Process
6.2.4 Support . . . . . . . . . . . . . . . . . . .
6.2.5 Using the APIs . . . . . . . . . . . . . . .
6.2.6 Authentication and Ticketing . . . . . . .
6.2.7 Tagging issue . . . . . . . . . . . . . . . .
6.2.8 Javascript . . . . . . . . . . . . . . . . . .
6.2.9 External Workers . . . . . . . . . . . . . .
6.3 Summary . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
58
58
60
62
63
63
65
65
66
67
67
68
68
69
69
69
70
7 Discussion
7.1 Answering the First Research Question . . .
7.1.1 Comparison with Related Work . . .
7.2 Answering the Second Research Question . .
7.2.1 Comparison with Related Work . . .
7.3 Further Observations . . . . . . . . . . . . .
7.3.1 Third-party Developer Segmentation
7.3.2 Method . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
72
72
74
74
75
77
77
78
vi
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
8 Validity Discussion
80
8.1 Internal validity . . . . . . . . . . . . . . . . . . . . . . . . . . 80
8.2 Construct validity . . . . . . . . . . . . . . . . . . . . . . . . . 81
8.3 External validity . . . . . . . . . . . . . . . . . . . . . . . . . 81
9 Conclusions
83
9.1 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
vii
List of Tables
2.1
2.2
Pre-study data . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Data collection . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1
3.2
Software platform, possible denominations . . . . . . . . . . . 25
Roles in SECOs . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.1
5.2
5.3
Software quality model (ISO/IEC 9126-1), own synthesis . . . 49
Usability objectives and possible measures, an example . . . . 52
Combining the standards . . . . . . . . . . . . . . . . . . . . . 56
viii
List of Figures
1.1
1.2
Software Ecosystem, Roles and Elements . . . . . . . . . . . . 6
Hackathon activities . . . . . . . . . . . . . . . . . . . . . . . 11
2.1
2.2
Retrospective questionnaire . . . . . . . . . . . . . . . . . . . 17
Happiness level graph . . . . . . . . . . . . . . . . . . . . . . . 18
3.1
3.2
3.3
Taxonomy, Bosch (2009) . . . . . . . . . . . . . . . . . . . . . 30
Taxonomy, Bosch (2012) . . . . . . . . . . . . . . . . . . . . . 30
The Onion Model . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.1
6.2
6.3
Content Anywhere . . . . . . . . . . . . . . . . . . . . . . . . 60
CAN architecture. A high level representation . . . . . . . . . 61
Content Anywhere Ecosystem . . . . . . . . . . . . . . . . . . 62
ix
Chapter 1
Introduction
1.1
Background
When observing the different smartphones ecosystems it is easy to notice
how the number of software applications available for the end-users has been
growing exponentially; there are applications for any possible use one can
think of, and some that one cannot even think of. At the present stage,
potentially anyone would be able to develop an application, and even the
step “from-zero-to-superhero” is not that huge anymore; meaning the step
from being a novice to reaching a satisfactory level of expertise. In these
contexts the barriers for developing and marketing applications have significantly lowered (Yoo et al., 2010). Barriers can be various kinds of costs and
difficulties; first of all learning, accessing tools and distribution. To summarize, it is possible to say that innovation has been democratized (Yoo et al.,
2010).
These kinds of settings are usually referred to as software ecosystems
(Hanssen and Dybå, 2012; Jansen et al., 2009b; Bosch, 2012; Scacchi and
Alspaugh, 2012). In a software ecosystem there typically is an organization
controlling the platform, and third-party developers, or at a general level
complementors, that produce complementary assets for the platform. The
platform offers third-parties a means to reach its heterogeneous customer
base or end-users. By producing the complementary applications the thirdparties aim at fulfilling the different needs of the different end-users groups.
Furthermore, software organizations are becoming more and more permeable and linked to one another. Doing so, platform owners accept to shift
part of their design capabilities and control to third-parties, in order to bring
in complementary components (von Hippel and Katz, 2002; Ghazawneh and
Henfridsson, 2010). These third-parties, in turn, use the platform produc-
1
CHAPTER 1. INTRODUCTION
2
ing heterogeneous and potentially unexpected results (Yoo et al., 2010). In
other words, a software ecosystem is the result of a strategy where software
producing organizations open interfaces to the external world in order to
harness open innovation. In fact, there is a trend in the software industry
where organizations open up successful product lines to third-party development (Bosch, 2012), but software ecosystems can also grow around an open
source platform (Kilamo et al., 2012) (Jansen et al., 2012) or an open standard (Jansen et al., 2012). However, there is no guarantee that enacting
a software ecosystem strategy will lead to a great success (Ghazawneh and
Henfridsson, 2010).
The fundamental prerequisite for the birth of a thriving ecosystem is the
presence of a software platform with a layered modular architecture (Yoo
et al., 2010). Because of such an architecture, the software platform can
be used not only as a standalone product, but it allows third-parties to
innovate using the services the platform exposes (Gawer and Cusumano,
2008; Yoo et al., 2010). From the technological perspective this innovation,
driven by third-party, is enabled by creating an architecture providing interfaces (Gawer and Cusumano, 2008). In other words, the enablement occurs
providing resources as APIs(application programming interfaces) and SDKs
(software development kits) (Yoo et al., 2010).
In this thesis we refer to these resources as platform boundary resources
(Ghazawneh, 2012). These boundary resources are the interface that allows
the third-party developers to access the services and resources offered by the
software platform without knowing too many details.
Within platform boundary resources, technical boundary resources are
not the only means to enable and facilitate the third-parties; it happens
also through social boundary resources(Ghazawneh and Henfridsson, 2010).
These social resources are different forms of support: as documentation;
intellectual propriety rights (IPR) agreements; and a market place, just to
name a few. From the business perspective, the platform owner needs to
provide the third-parties with incentives; often in the form of viable business
models (Bosch, 2012). In other words the possibility to benefit from the
software ecosystem.
From the industrial economics perspective a software ecosystem typically
fits the definition of a two-sided market, and it shares similar high-level dynamics. Two-sided markets have a platform owner and two distinct groups
of users(also called players or actors) on each side of the platform. The
platform is a product or service that connects these two groups (Eisenmann
et al., 2006). These are rather complex market situations that have many
issues to be taken into account. In contrast to the traditional industry value
chain, from the platform owner point of view, costs and revenues are on both
CHAPTER 1. INTRODUCTION
3
sides; though one of the sides is often subsidized (Eisenmann et al., 2006).
For example Adobe is charging writers for the software that creates PDFs,
but has a give-away policy for the reader. The setting is not new, although
it has evolved significantly (Eisenmann et al., 2006).
One of the first examples of a two-sided market is the credit card payment
system that connects consumers and merchants. Later on appeared operating systems and video game consoles; although they look similar they have
different market dynamics. Then Google and all its services, linking the endusers of its services with advertisers. Last but not least the ecosystems existing around the smartphones’ operating systems; interesting, among other
things, for the multi-homing issues third-parties have to face. Multi-homing
is the problem, for third-parties, of deploying as software applications in all
the software platforms. For this reason, often third-parties need to make a
choice about which ecosystem to participate in. All the provided examples
share common characteristics.The platform provides the infrastructure and
rules that enable interactions between the two groups.
Interactions, within and across the two groups, are the engine of software
ecosystems (Hanssen, 2012) and generate network effects (Eisenmann et al.,
2006). Network effect is a term used to describe the phenomena involving
and affecting the users on both sides of a two-sided market. Such phenomena
are responsible for creating virtuous circles (Cusumano and Gawer, 2002);
to be exact, only a subset of those are. This subset can be referred to as
“positive cross-side network effect” (Eisenmann et al., 2006) using another
author’s denomination. Other possible, but less specific, denomination are
“positive-feedback effects” (Cusumano and Gawer, 2002) and “positive network externalities” (Cusumano and Gawer, 2002) (Yoo et al., 2010).
In two-sided markets it is fundamental to consider different kinds of network effects: same-side or cross-side network effects; each of those can be
positive or negative (Eisenmann et al., 2006). An example of positive sameside network effect is that people join Facebook or choose WhatsApp over
similar messaging services because more and more of their acquaintances are
part of the service. Same-side network effect can also be negative: usually
the group of users making transactions with the other side of the platform
prefers to have less competitors.
A positive cross-side network effect occurs when one side of the market is
attracted to the platform because of the large user base on the other side of
the market. There could even be negative cross-side effects. For example endusers might get annoyed by the amount of advertisers on a platform (e.g. TV
content providers, Google) and be willing to join another platform because of
that. This, of course, requires the presence of a competitor for the described
mechanism to happen. This last condition is not always obvious, since often
CHAPTER 1. INTRODUCTION
4
there are winner-take-all dynamics in two-sided markets (Eisenmann et al.,
2006). Meaning that, typically in a two-sided market almost all the endusers are using a single platform. The platform can be controlled by a single
company (e.g. PC operating systems) or be shared among companies (e.g.
DVD standard) (Eisenmann et al., 2006).
In two-sided markets a big challenge for the company controlling the
platform, is to generate and harness positive network effects. A particular
pricing policy, for example, may be one way to generate such effects (Eisenmann et al., 2006).
In the specific context of software ecosystems, attracting third-party development is a major strategical concern (Yoo et al., 2010); it is one way
of generating positive network effects (Eisenmann et al., 2006). In fact, the
higher the number of applications the more the end-user can benefit from
the ecosystem (Huang et al., 2009; Kabbedijk and Jansen, 2011); thus the
ecosystem thrives. To achieve this objective, enabling third-party development is an important issue. That happens in a number of ways that may
have a different magnitude of importance. It starts from technically giving
the possibility of interacting with the platform and developing software applications on top of it; to providing realizable business models; to support
and facilitate in various ways the software development processes.
1.2
Problem Area
At a general level, there is still not an agreed definition or theory about software ecosystems nor sufficient research on “real-word” SECO’s (Manikas and
Hansen, 2013); some authors call for more empirical studies of exploratory
or longitudinal nature (Hanssen, 2012) (Kilamo et al., 2012).
Within this field third-party developers are perceived as crucial by many
authors. The relation between the software platform owner and third-party
developers has been defined as “the engine of a software ecosystem” (Hanssen,
2012), and among the challenges encountered by platform owners, there is
the ability to attract developer to produce complementary assets (i.e. software applications) for the platform (Ghazawneh, 2012). So the main aim of
software platform owner is to facilitate and boost the development process.
At the same time there is an intrinsic tension in the relationship between the
software platform and the third-party developers, that originates from conflicting needs (Bosch, 2009). On one hand the the software platform owner
wants to facilitate the development processes as much as possible to harness
the potential innovation and the possibility of addressing the needs of heterogeneous users (von Hippel and Katz, 2002); this means a shift of design
CHAPTER 1. INTRODUCTION
5
capabilities (von Hippel and Katz, 2002) towards the third parties. On the
other hand the platform owner still wants to retain control of the platform,
and is reluctant to give up part of the relationship with the end-users to the
third-parties (Bosch, 2009; Ghazawneh, 2012).
Finally, these relations and the described mechanism exist through what
has been referred to as platform boundary resources; they are an interface
between entities. These resources, on a general level, can be described as
the attempt of the platform owner to address the needs of the third-party
developers; these resources range from technical solutions to viable business
models (Bosch, 2009). This calls for additional research studies on the topic
(Ghazawneh, 2012), particularly in relation to practices that attract thirdparty development. To our knowledge, platform boundary resources in a
software ecosystem were investigated from the perspective of the platform
owner (Ghazawneh, 2012); Hence another suggested direction is to analyze
their role from the perspective of third-party developers.
A simplified view of the problem area is offered by Figure 1.1. In this
figure we can see the three basic roles within a software ecosystem, as well
as the main elements and the relations between the elements and roles.
1.3
Research Problem
The success of a software ecosystem is determined by the software application
built on top of it (Bosch, 2009). It follows that third-party developers are
undoubtedly a key element: they play a major role in making attractive for
the users to join the software ecosystem. Third-party developers develop
heterogeneous software applications that complement the software platform,
hence making the software ecosystem more appealing for heterogeneous endusers with different needs and living in different contexts.
Observing the problem from the third-party developers perspective:
What makes third-party developers join a particular software
ecosystem and invest in the development of applications?
One of the main drives for the developers to join a software ecosystem is
certainly the economic reasoning involved (Eisenmann et al., 2006; Huang
et al., 2009) (e.g. size of the market, competitors, investments and risks etc.).
However, a maybe obvious, fundamental prerequisite is that the third-party
developers are actually able to develop software applications. We mean that
another factor that definitely plays a major role in the ecosystem’s dynamics
is the ease, for third-party developers, to develop applications for the software
ecosystem. In fact “Minimizing the effort required by developers...” (Bosch,
CHAPTER 1. INTRODUCTION
Figure 1.1: Essential roles and elements of a software ecosystem
6
CHAPTER 1. INTRODUCTION
7
2009) to develop applications on top of the software platform is indicated as
a key factor for the success of the software ecosystem (Bosch, 2009).
The interaction of the third-party developers with the software platform
is mediated by platform boundary resources (Ghazawneh and Henfridsson,
2012; Ghazawneh, 2012)(See Figure 1.1). So:
Minimizing third-party developers effort requires acting on the
platform boundary resources; we refer to minimizing third-party
developers effort as enabling third-party development.
At the same time, the effort or enablement is perceived by third-party
developers. So:
To understand how to enable third-party development further,
it is crucial to understand the experience of third-party developers
in using platform boundary resources to create software applications.
We studied the problem in light of the practical challenge F-secure had in
creating a software ecosystem around their product called Content Anywhere.
The research problem is condensed in the following research questions:
RQ1 How does F-secure enable third-party development through platform
boundary resources?
RQ2 What does third-party developer experience consist of in F-secure’s
software ecosystem?
The first question is concerned with the current state of the practice of
Content Anywhere Ecosystem in relation to its boundary resources offered
to third-party developers. The second question, is concerned with how the
platform boundary resources and Content Anywhere Ecosystem in general
are perceived by third-party developers.
To answer this questions, the approach we chose was to find relevant elements for discussion starting from the literature concerning software ecosystems and their internal dynamics. We also considered literature concerning
API’s usage and, in general, resources offered to third-party developers as
well as traditional usability and user experience material. The literature part
was complemented with empirical data collection. In order to collect data
in a convenient and semi-controlled way, both for the researchers and the
developers, we used a hackathon as the setting to conduct our research. A
hackathon is described in the next section.
CHAPTER 1. INTRODUCTION
1.4
8
Hackathon
In order to explore and gain a better understanding of the the issues we
listed when presenting the research problem, we decided to observe and collect data during a hackathon organized by F-secure. During this hackathon,
teams of F-secure’s employees were developing different kind of software application prototypes. The software applications had different scopes, but they
were all using the services offered by F-secure’s Content Anywhere Ecosystem
through the third-party APIs; along with other application-specific technologies.
1.4.1
Hackathons’ Description
Hackathon stands for hacking marathon. Other denominations might also
be hack day, hackfest or codefest, and even webfest if focused on web development. A possible explanation of these different names comes from one
of the the informal interviews, part of the lightweight pre-study on how to
organize successful hackathons. According to the interviewee that organized
a hackathon at CERN (Centre, 2012) called Webfest, the choice of using a
wording including hacking was discarded because some people would have
associated it with something related to computer crime. Regardless of the
terminology used to describe it, a hackathon is:
“An event where people in small groups participate in an intensive prototyping activity for a limited amount of time.” (Raatikainen
et al., 2013)
Usually the prototyping activity is software development, particularly
web and mobile applications, but it could be otherwise. Recently at Aalto
university there has been a 48-hours hackathon with 3D printers (AaltoES,
2013); at the OKfestival1 , that took place in Helsinki in September 2012,
there was an open journalism hackathon; in the Cloud Software Hackathon2
in March 2013 in Vuokatti there was a business development hackathon. The
prototyping activity typically goes from the idea generation to the demonstration of a working prototype. In that case the main activity consists solely
of the idea generation and its communication by some form of visualization,
the word jam (Osvald and Robert, 2008) might be more appropriate.
An informal report of a hackathon event can be found on Wired in the
article “The Hackathon Is On: Pitching and Programming the Next Killer
1
2
http://okfestival.org/
http://www.cloudsoftwareprogram.org/
CHAPTER 1. INTRODUCTION
9
App” (Leckart, 2012). The event can last from one night like in Facebook’s internal hackathons (Burnham, 2012) to some days like in the case of F-secure’s
internal hackathon; typical formats are a 24-hours and 48-hours hackathons.
We use the term internal hachathons because we want to specify that only
the employees of a specific company participate.
1.4.2
Hackathon Activities
An example of the different phases of an hackathon is given in Figure 1.2.
The first phase is the idea generation, and it can happen in different ways.
Either some participants pitch their idea to the other participants that then
decide who to join, or the team does some brainstorming activity. All the
different options for idea generation may happen before the start of the actual
hackathon. The second phase involves forming a team, as explained in the
previous description it can happen before or after the initial idea generation.
Ideally the team should include a designer and a business oriented person in
addition to coders. However, in many cases the team is only composed of
coders.
The main phase is clearly the development activity. The members of the
team usually do a little bit of planning to divide tasks and define the characteristics of the minimum viable product. To this end, the coders typically
have an incremental approach, since it might be hard to make an estimate
of the required time and the difficulties one may encounter. So they try to
achieve basic objectives at first and then add more in the following iterations
if there is time left; team members can help other members in case their
tasks are completed and others are having difficulties.
When the time is up, the teams have to present their prototype and answer questions from the audience. After that, the best prototypes can receive
different kinds of prizes. Another phase that is not mentioned in the example picture is the “set-up” phase. As for the idea generation, this phase can
happen before the actual hackathon event. It typically comprises setting up
the required tools (eg. installing certain IDE, or particular libraries), getting
acquainted with some specific technologies by reading the documentation
and so forth. These last activity as well the idea generation part can happen before the actual hackathon; with the goal of saving the, already short,
available time for focusing on the prototype development.
We provided an account of typical hackathon activities. This information
have been condensed from: on-line articles; few scientifically conducted studies; informal interviews in the pre-study phase; personal experience. However, it cannot be denied that there is no formal structure for a hackathon, as
there is no standardized definition of what constitutes a hackathon; except
CHAPTER 1. INTRODUCTION
10
maybe the common knowledge that it involves some prototyping activity.
Actually, hacking itself lacks formality by definition.
1.5
Scope of the Thesis
Without any doubts, economic reasoning regarding viable business models
is a major concern in the context of third-party development; so in this
regard it is important to provide guidance to developers (Bosch, 2012). In
addition, there are issues related to the specific business relations between the
third-parties and the end-users; issues about IPR related to the third-parties’
innovations; and issues related to the impact these two factors have in the
likelihood that third-parties join the software ecosystem (Huang et al., 2009).
However, this study focuses on issues related to the usage of the platform
boundary resources exposed to the third-party developers in the context of
a specific software ecosystem. Estimations on the different impact that the
different factors have (i.e. various economic reasoning or technical and legal
concerns), in making third-parties participate in a SECO, is also kept out of
the objectives of this Master’s thesis.
1.6
Thesis Outline
This master’s thesis starts with an introductive chapter where we depict the
general context in which reside the specific issues that this study is concerned
with. This first chapter includes also the description of the specific target
of this study and the research objectives. Chapter 2 presents the research
methods used to realize this study. Chapters 3, 4, and 5 are concerned with
established knowledge from the available literature and standards. Those
chapters provide basic and more advanced concepts, define the terminology
used throughout the thesis, as well as possible measures. Chapter 6, after
the introducing Content Anywhere Ecosystem, presents the result of our data
collection and analysis in the form of an evaluation. In Chapter 7 results are
first discussed in relation the research questions, and then in relation to the
findings of other studies that are related to our problem domain. In Chapter
8 we discuss the validity of our study. Chapter 9 gives a summary of the
main contributions of this master’s thesis in relation to the research problem
and, finally, we give suggestions for future work.
CHAPTER 1. INTRODUCTION
11
Figure 1.2: A visualization of a generic hackathon’s activities (source: Tim
Boelaars (Leckart, 2012)).
Chapter 2
Research Method
This research work conforms to a case study (Yin, 2002) approach to gain
a description of the state of the practice of F-secure’s Content Anywhere
(CAN for short) ecosystem. The description is presented in light of the
experience of third-party developers using the platform resources offered by
CAN ecosystem; the aim is also to gain insights on new requirements in that
direction. The subject matter is essentially how the third-party developers
perceive the platform resources of the CAN ecosystem according to their
expertise and experience.
In the literature part we provide an account of the research context; we
collected basic and more advanced concepts and definitions found in the existing literature. Specifically concerning Third-party developer experience
we relied on an expert’s opinion to find appropriate reference material. Regarding the empirical part, we essentially relied on F-secure’s developer professional opinion for the evaluation. F-secure’s internal hackathon facilitated
the process.
In addition, the study had an explorative nature; for this reason we
deemed appropriate to use principles borrowed from grounded theory (Myers, 2008), when conducting data analysis. For example through the use of
codes.
2.1
Empirical Data Collection
The most consistent part of the data was collected during a three-day-long
hackathon event in October 2012, in Espoo at the Aalto Design Factory1
premises. If not collected directly during the event, the data the related
to the hackathon. Specifically, we conducted individual interviews with the
1
http://www.aaltodesignfactory.fi/
12
CHAPTER 2. RESEARCH METHOD
13
F-Secure employees participating in the hackathon; mainly developers, but
also members of the support team. The individual interview rounds started
immediately in the week after the event and were concluded approximately
within a month from the hackathon. The empirical study is, in fact, mainly
concerned with the first trial of a hackathon in F-secure.
The objective of this hackathon was to develop three applications using
the platform boundary resources; each of the applications had a different
scope and targeted different devices. For the company, this trial hackathon
had the double function of creating software applications to showcase the
capability of CAN as a platform, and at the same time test the platform
in a more rapid and extensive way than usual testing. Additionally, there
was a curiosity in F-secure about hackathons as a company practice to boost
innovation.
While initially the idea of a Hackathon emerged as a practice to boost
innovation in F-Secure, the idea of using it to study the platform and learn
from it arose later. These latter concerns resulted in starting a more rigorous
study on the whole experience in the form of a case study. To this end, the
hackathon had been carefully planned before its start; the planning activity
included agreeing upon structure, length, focus and topics. A fundamental
part of the planning and preparation activity was a lightweight pre-study
(summarized in table 2.1) on how to organize successful hackathons. In this
regard, we found information on blogs and on-line articles but few scientifically reported experiences (Crowston et al., 2007) (Lapp et al., 2007). In addition to this we conducted some semi-structured informal interviews aimed
at collecting insights from subjects experienced with hackathons. There
has been a series of hackathons open to a wide audience organized and colocated in a conference event called “Open Knowledge Festival”2 in Helsinki;
in this event we observed and learned about good practices for successful
hackathons. We also interviewed one of the key figure of the Aalto University’s Windows Phone community3 that is active in organizing hackathons
with Aalto Entrepreneurship Society in the various “Build it”4 events they
had.
The article from Crowston et al. (2007) offered guidance on how to approach data collection and analysis. They provided an account on the role
of face-to-face meetings occurring at periodical conferences of FLOSS. The
term refers to Free/Libre Open Source Software (software developed and licensed under open source license) and the study is about the role of these
2
http://okfestival.org/
http://windowsphoneaalto.org/
4
http://aaltoes.com/build-it/
3
CHAPTER 2. RESEARCH METHOD
Technique
Interviews
Documentation
14
Data
Two hackathon organizers
Two hackathon participants
Blogs and on-line articles
Table 2.1: A summary of data collection for the lightweight pre-study on
how to organize successful hackathons
intensive software development activities carried out at the conferences. The
developers participating in FLOSS projects are typically part of distributed
teams, hence these face-to-face meetings are not a usual setting. Due to the
similarity of the setting and the phenomenon being observed, we took the
approach the authors used in the study as a reference.
2.1.1
In the Hackathon
One week before the hackathon there had been a meeting at F-secure’s
premises in Helsinki. Present in the meeting were almost all the F-Secure
employees that responded to the open call and volunteered to participate
in the hackathon; in addition to a few product owners and members of the
support team. A researcher from Aalto University participated in this preliminary meeting. The researcher used the meeting to collect information
about the architecture and current status of F-secure’s CAN. Additionally,
the researcher introduced himself and the research activity that was being
carried out. This was done with the goal of making the F-Secure people as
comfortable as possible with the research activity, enhance future collaboration, and gain their trust (Myers, 2008).
This preliminary meeting had a double role. First of all, some of the
fellas had the opportunity of pitching their previously prepared initial ideas
for the hackathon and communicating the technologies they intended to to
use. In this way the other participants could choose which team they wanted
to join according to their preferences; in terms of technology. As explained
when presenting hackathons activities , this phase can happen before the
actual hackathon. Secondly, a product owner and other members of the
support team were providing instructions to the participants. Specifically:
illustrating the general architecture of CAN; some detail on the APIs; practical information on where to find documentation and register as a developer
to get authentication and download the needed tools. This activity can be
CHAPTER 2. RESEARCH METHOD
15
considered as a sort of “bootcamp” (Lapp et al., 2007). We need to specify that the developers that participated in the hackathon were not familiar
with CAN and its APIs, they were all working on different projects within
F-secure.
During the hackathon our general approach, as researcher, was to observe
and learn rather than disturb the participants thus hindering their work. We
used lunch breaks and other common gathering moments to acquire additional information and become familiar with the participants; following the
same approach as Crownstone et al. (Crowston et al., 2007). Another objective we had was to collect material to present the hackathon at F-secure
internally and promote the participation to future ones; this provided us
with the opportunity to collect observational data such as photos and video
recordings.
The data collection consisted mainly of observations, and post-hackathon
interviews; In table 2.1.2 there is a summary of the data collection techniques and the type of data collected. Three people observed the hackathon
for the majority of the time, one person occasionally. These observations
were annotated in the researchers’ notes. We recorded video of the common
sessions like the opening, morning briefings, and the closing demo session.
Additionally we have informal audio recording of the discussion going on after the hackathon. This observational data is complemented with the slides
of the presentation given in the common session and an on-line chat log of
the discussion between the participants. This last chat log contained the
communication between the participants and the support team. At least one
researcher was constantly checking the chat conversation. This had a double
function: constantly checking participants needs and solving practical problems (e.g. food and other practicalities); complementing the researcher’s
observation notes. After all, since we did not want to disturb the participants, that was the only means to know what was happening if they were
not communicating verbally and they were totally dedicated to software development.
Other data was collected in the form a retrospective session; in figure 2.1
we can see the retrospective questionnaire that was given to the participants.
This kind of session is a state-of-practice method in the context of agile
software development, and participants were familiar with it because it is
also applied in their daily work at F-secure. These retrospective session
happened twice, during lunch on the second and third days. As we can see
in Figure 2.1 the retrospective was a paper having three spaces for comments
titled: “keep”, “drop”, and “try”. These referred to, respectively, practices
that should be kept, practices that should be abandoned, and new practices
that should be tried. We also stored material, such as invitations sent by
CHAPTER 2. RESEARCH METHOD
16
e-mail and slides from the preparation meeting.
2.1.2
Interviews and Feedback Meeting
As introduced at the beginning of this section, within the weeks following
the hackathon we conducted hour-long, semi-structured interviews with 12
participants; in the meanwhile we also interviewed the two main organizers.
The interviews were conducted partially in Finnish and partially in English;
depending on which language F-Secure employee were most comfortable expressing themselves in. A researcher from Aalto University and a hackathon
organizer from F-Secure were present throughout the interviews.
A questionnaire was prepared and handed out after the hackathon to all
developers and support team and sent electronically again with an interview
request. The purpose was to remind developers what kinds of experiences
they are expected to reflect on later in the interview. The questionnaire was
filled, corrected or finalized in the interviews. This was done because the
participants were probably not motivated to fill out the questionnaire directly
after the hackathon. Additionally, we thought this would add reliability to
the data obtained by interviews done in the weeks following the event. In
the questionnaire the developers evaluated the activities that were assumed
as hypothetical development activities. The developers were also asked to
draw a trend of the happiness level (figure 2.2) during the three days, and at
the same time, we asked what was the cause or what happened, especially in
cases of changes in feelings.
The interviews were semi-structured and their main points, even though
planned beforehand, were shaped by the observation made during the hackathon.
The interviews started with an informal talk about the participant’s role in
F-secure and the kind of research we are conducting, explaining the importance of the interview for that aim. The feedback, about the importance of
feeling that the effort the participant put in is being valued, emerged also
regarding other aspects of the hackathon. We recorded and subsequently
transcribed all the interviews. In addition, as an extra precaution, we took
notes of the answers. As the interview rounds proceeded and we started
analyzing the data, we tended to focus on some aspects more then others.
After having coded and analyzed the data, a researcher from Aalto University gave a presentation that was summarizing and grouping the data from
the hackathon around certain topics. The results of the Hackathon were discussed with the product owner and a couple of software architects that had
CHAPTER 2. RESEARCH METHOD
17
Figure 2.1: The retrospective questionnaire filled by one of the participantsl.
CHAPTER 2. RESEARCH METHOD
18
Figure 2.2: A graph of the happiness level as drawed by one of the participants.
CHAPTER 2. RESEARCH METHOD
Technique
Interviews
Observations
Documentation
Questionnaires
19
Data
9 participants, transcription,
1 hour each, semi-structured
3 support persons, transcription,
1 hour each, semi-structured
Videos, photos, researcher notes,
subjective experiences, skype
chat log
Presentation slides
E-mails from organizers
Satisfaction level graph
Keep, drop, try table
Table 2.2: A summary of data collection techniques and key data
participated in the hackathon. The results constituted a basis for the following discussion on the main issues of the software platform resources, and
hackathons as an industry practice. The results in terms of the hackathon
as an industry practice are reported in an article (Raatikainen et al., 2013).
F-secure people noted down all the issues they regarded as important on
post-its during the researcher’s presentation. Specifically some issues were regarded by F-Secure’s people as minor or non-relevant details. As researchers,
we did not want to take the responsibility of making a selection of the results.
After that the post-its were attached to a whiteboard, grouped in clusters depending on their relation, and the clusters named accordingly. That allowed
the F-secure’s people present in the meeting to give the different conceptual
level to the different issues, prioritize them, and think of responsibilities for
future actions. In that occasion, besides presenting our results and answering questions, we recorded the meeting and took pictures of the visual data
produced.
2.2
Data Analysis
The collected data was translated into a textual form (if possible). The
data being analyzed comprised the transcribed interviews, the log of the
chat that included participants and support team, and the observers’ notes.
With the aid of Atlas.ti5 , segments of text were assigned to categories; in the
software the categories are named codes. These codes are basically labels
5
http://www.atlasti.com
CHAPTER 2. RESEARCH METHOD
20
that are assigned to quotations from the text. Using the codes it is possible
to query the software and build network views that help visualizing related
information.
The codes were selected according to our initial assumptions on the developer activities, and the main factors influencing their experience. We started
our analysis activity with a small set of codes. While proceeding in the data
analysis the set of codes evolved. New codes were added and as we gained
more understanding of the data also the meaning of the codes changed. In
fact some code became a bit too generic and the introduction of more specific
codes was required. The use of more than one code for a segment of text was
not uncommon. In this case, a bigger segment of code had a more generic
code and a smaller portion of that same segment was assigned a more specific code. It also happened that the same text segment was assigned with
two codes if that part of text was bearing relevant information for both the
categories the two codes represented; or one of the two codes indicated a
required clarification for that category, for example “positive” or “negative”.
The results from the “keep-drop-try” table where collected in a table
to facilitate the feedback meeting with the hackathon organizers and highlight recurring or conflicting issues; this data was more concerned with the
hackathon as a company practice. The developer’s activity questionnaire and
the hand-drawn happiness level graph we gave to the developers, was filled-in,
or completed, or anyways discussed during the individual interviews. Those
document actually constituted an important part of the interviews. Therefore the data concerning those documents is embodied in the interviews’
transcriptions and analyzed in the same way we described above.
Chapter 3
Software Ecosystems
Software ecosystems, SECO (Jansen et al., 2009b) for short, are the general
setting within which lies the research interest of this Master’s thesis. It is a
rather new and active field of research (Hanssen and Dybå, 2012), where there
are new business models, new relationships and modes of interaction between
different actors that create networked communities. These networked communities are tied together by the interest in a certain technology (Hanssen
and Dybå, 2012), namely a shared software platform.
The software platform as a product and its services have a fundamental
role in connecting the activities of clustered firms constituting an ecosystem
(Baldwin and Woodard, 2008). So it is already clear how software ecosystems
are characterized by an interplay of social and technological aspects (Hanssen
and Dybå, 2012). This interplay and the new relations between different
actors bring a change in the field of software engineering to aspects related
to collaboration, shift of control and innovation (Hanssen and Dybå, 2012;
Yoo et al., 2010; Ghazawneh and Henfridsson, 2012)
Since it is a relatively new field of research we first decided to analyze
the most relevant definitions of software ecosystems found in the literature,
and we attempted to highlight the characteristics of software ecosystems
from those definitions. Software ecosystems can also have different origins
and thus assume different forms (Bosch, 2012), so to clarify the concept we
deemed necessary to provide an account on how software ecosystems can be
classified. Within this context it is also relevant to present the different roles
that participants in a software ecosystem can assume (Manikas and Hansen,
2013). In analyzing software ecosystems from the existing literature we faced
some challenges. In fact the concept of software ecosystems can be vague and
different, and there is also a quite high variability in the use of terminology
(Hanssen and Dybå, 2012); even within a certain research community.
21
CHAPTER 3. SOFTWARE ECOSYSTEMS
3.1
22
Definition of Software Ecosystems
The literature review from Manikas and Hansen (Manikas and Hansen, 2013),
addresses the objective of providing a shared and comprehensive definition of
the term software ecosystem. The literature body comprises ninety articles,
half of which did not provide a definition of the term software ecosystem. The
authors explain this with the fact that, either those articles are relying on
previous research to provide context and definitions or the main focus of the
articles was not the general topic of SECOs. Within those articles defining
the term, only a few articles provide their own definition of the term; in two
of these few articles own definitions coexist with another definition from the
literature (Manikas and Hansen, 2013). The remaining articles used one or
more definitions from previous research works. Four definitions in particular
are the most quoted.
The oldest definition of SECO found in the literature (Manikas and
Hansen, 2013) is from a book by Messerschmitt and Szyperski published
in 2005. However, this definition was excluded from Manikas and Hansen’s
analysis. The rationale behind this is that, despite the fact that the definition is concerned with software and relationships between parts, it has
exclusively a technical focus. Whereas the ones that are discussed further in
this thesis present a wider perspective (Manikas and Hansen, 2013); Moreover, counted together these definitions are cited by the majority (65%) of
the papers providing a definition (Manikas and Hansen, 2013).
The first of these definitions is from Jansen et al. (2009b):
“We define a software ecosystem as a set of businesses functioning as a unit and interacting with a shared market for software
and services, together with the relationships among them. These
relationships are frequently underpinned by a common technological platform or market and operate through the exchange of information, resources and artifacts” (Jansen et al., 2009b).
This definition presents a list of key elements. Relationships appear to be
a central concept and, in this regard, the exchange of information, resources
and artifacts is a means through which different actors (businesses in the
definition) relate to each other. The common software platform or market
place assume the role of important enabler but are not presented essential.
The definitions that can be regarded as having a wider-perspective are
by Bosch (2009), and Bosch and Bosch-Sijtsema (2010b,a):
“A software ecosystem consists of the set of software solutions
that enable, support and automate the activities and transactions
CHAPTER 3. SOFTWARE ECOSYSTEMS
23
by the actors in the associated social or business ecosystem and
the organizations that provide these solutions” (Bosch, 2009).
“A software ecosystem consists of a software platform, a set of
internal and external developers and a community of domain experts in service to a community of users that compose relevant solution elements to satisfy their needs” (Bosch and Bosch-Sijtsema,
2010b,a).
The first of these two definitions presents a software ecosystem as a part
of a bigger picture that comprises also a social and business ecosystem. The
software ecosystem with its solution is described as the foundation upon
which the related social or business ecosystem can thrive. The second definition provides a view where the software ecosystem comprises all the other
elements; these elements are the different actors together with their relationships and the software platform, which is regarded a fundamental element.
The definitions presented above share three common points: a common
software, relationships between actors, and a business element. The business
element is not to be intended only as direct revenues or profit, but generally
as various benefits the different actors can get from the participation in a
SECO (Manikas and Hansen, 2013). Concerning relationships it appears
that a symbiosis aspect is common to all the listed definitions (Manikas and
Hansen, 2013); perhaps the use of the word ecosystem itself implies that.
The wording “symbiotic relationship”, though, was explicitly used only by
Messerschmitt and Szyperski in their book; however, as explained before,
Messerschmitt and Szyperski had an exclusively technical point of view.
Besides these commonalities we can notice also differences. For example,
the software platform has a more fundamental role in the last definition
(Bosch and Bosch-Sijtsema, 2010b,a) than in the others (Jansen et al., 2009b;
Bosch, 2009). Also, different aspects of the relationships are highlighted in
each definition: In the first definition Bosch describes the relationships as
part of a social or business ecosystem (Bosch, 2009); the definition from
Bosch et al. refers to communities (Bosch and Bosch-Sijtsema, 2010b) (Bosch
and Bosch-Sijtsema, 2010a); and Jansen et al. explain that SECOs work
exchanging “information, resources and artifacts” (Jansen et al., 2009b).
Based on the analyisis of the previous definitions Manikas and Hansen
suggest their own definition. SECOs are described as interactions between
different actors that share a technological platform and produce solutions and
services (Manikas and Hansen, 2013). The authors also add that different
actors have different motivations, different business models and have a symbiotic relationship with each other. The symbiotic relationship exists also
CHAPTER 3. SOFTWARE ECOSYSTEMS
24
between the actors and the ecosystem as whole (Manikas and Hansen, 2013);
meaning that, actors benefit from participating in a thriving ecosystem and
the success of the ecosystem is determined by the actors’ activity.
To conclude, the different definitions of a SECO and descriptions of its
comprising elements share some key aspects. However, we can observe that
there is no agreed definition of SECOs. The presence of many definitions,
and their relative differences, can be explained by the fact that SECOs are
a quite new area of research. It is also true that, different researchers and
research communities focus their interests in different specific aspects of software ecosystems (Manikas and Hansen, 2013; Hanssen and Dybå, 2012). For
example, from the software architecture community and the information systems community to the economics and management strategy community or
sociology of organizations community.
Such a fragmented situation can also be explained by the fact that definitions usually have a functional purpose, specific to what the researchers are
interested in (Shadish et al., 1963). When providing definitions, scientists are
concerned with the prototypical features of the particular instances. In making a decision on which features are prototypical and which are peripheral,
scientists choose the one that are more crucial for understanding a certain
phenomenon.
3.2
Software platforms in SECOs
From the analysis of SECO definitions, it emerged the fundamental role of
what is commonly referred to as technological platform (Jansen et al., 2012;
Manikas and Hansen, 2013) or software platform (Kilamo et al., 2012; Bosch
and Bosch-Sijtsema, 2010a); depending on the author. Other authors use the
term central software technology (Hanssen and Dybå, 2012), others digital
product platform (Yoo et al., 2010). We prefer the term software platform
(See Table 3.2).
Within the topic of SECOs, the focus of this master’s thesis is on software
platforms. In fact, at the center of our case study there is a particular
software platform from F-secure.
Manikas and Hansen explain that the software platform should be designed in such a fashion that enables all the actors to be involved and contribute (Manikas and Hansen, 2013). This means that the software platform
needs to give the different actors the possibility to benefit from the ecosystem, where benefit does not only mean direct financial revenue; it can be
understood as the possibility to market the applications or the possibility to
achieve fame or gain knowledge, depending on the type of SECO.
CHAPTER 3. SOFTWARE ECOSYSTEMS
Term
Software platform
Technological platform
Central software technology
Digital product platform
25
Authors
Jansen et al. (2012); Manikas and
Hansen (2013)
Kilamo et al. (2012); Bosch and
Bosch-Sijtsema (2010a)
Hanssen and Dybå (2012)
Yoo et al. (2010)
Table 3.1: A table indicating the different terms that are to express what we
refer to as software platform in a SECO within this master’s thesis.
In that same direction it is also stated, citing Alspaugh et al. from 2009,
that the fundamental propriety of the technological platform is to be extensible beyond the organization that owns the platform (Hanssen, 2012).
The software platform is one of the two elements that constitute the value
shared by the different participant in the ecosystem; the other being the
business context supported by the platform (Hanssen, 2012). Among the
articles in Manikas and Hansen’s literature body, Hanssen’s article explicitly
mentions application programming interface (API) and software development
kit (SDK) when talking about ways in which to achieve extensibility.
Manikas and Hansen (Manikas and Hansen, 2013) do not mention directly
APIs and SDKs, even though Hansen’s article is included in their literature
body. Although in our opinion APIs and SDKs could fit, at a general level,
under the description of what “...allows the involvement and contribution of
the different actors.” (Manikas and Hansen, 2013). However, it cannot be
neglected that, when Manikas and Hansen explain further, it becomes clear
that they interpret the possibility of contributing in the ecosystem differently. They interpret the possibility to contribute as providing applications
developers with a delivery channel to reach end-users; like Apple Inc.’s “App
store” (Manikas and Hansen, 2013). They do not mention directly any resource that would allow contribution by effectively giving the possibility to
application developers to interact with the software platform; like APIs and
SDKs.
To sum up, APIs and SDKs and a digital market place are part of the
resources the software platform provides (Ghazawneh and Henfridsson, 2010)
to third party developers. These platform resources are fundamental when
describing the software platform and in general when discussing SECOs.
As an example, Ghazawneh’s doctoral thesis (Ghazawneh, 2012) concerns
the central role of what he calls “platform boundary resources” in third-
CHAPTER 3. SOFTWARE ECOSYSTEMS
26
party development for what he calls “platform ecosystems”. In his research
work these resources are seen as the means through which the third-parties
interact with the platform owner and vice-versa. The topic is covered more
extensively in the next chapter.
3.3
A Theory of Software Ecosystems
Towards the end of the previous Section, we introduced Hanssen’s view on
the software platform around which a software ecosystem exists. Hannsen’s
views are already condensed in a clearly framed theory of software ecosystems
(Hanssen, 2012; Hanssen and Dybå, 2012). The author proposes a theory
that aims at providing a generalization of SECOs and at being a reference
for future empirical studies on the topic; given that the existing literature
does not have a sufficient theoretical background (Hanssen, 2012).
In order to achieve these objectives, Hansen’s theory of SECO is based
upon the theory of “Organizational Ecology”. This theory can be found in
the work of Emery and Trist (1965) and of Trist (1977), which is actually the
natural evolution of the “Socio-Technical Theory” found in the work of Trist
and Bamforth in 1951. The fundamental principle of the socio-technical theory is that organizations are composed of two mutually dependent parts: on
one side there are people, their interactions and their knowledge; on the other
side tools and techniques (Hanssen, 2012). This principle then reflects on the
fact that any attempt to make a change, possibly an improvement, needs to
consider both parts together. The theory evolved to have a more external
focus and to be concerned with the relation between the organization and
its external environment, evidencing the existing interdependency. Besides,
of course the previously discussed interdependency between the social and
technical part within the organization.
The organizational environment is seen as an ecosystem (Hanssen, 2012);
this implies that the environment is seen as an open system, the borders of
the organizations are permeable and organizations have dynamic relations
between each other.
Hanssen presents three classes of organizational environments. In the
Class 1 environments, called keystone-centric, the organizations in the environment or ecosystem refer to a central organization. However this key player
has only partial control over the other organizations: this kind of relation
is not a superior-subordinate relation as in hierarchical organizations, but
it is defined as “interface relation” Hanssen (2012). As Cusumano puts it
“The company that leads exerts control not over others’ specific choices but
over the premises of choice. We call this ecological control, and presupposes
CHAPTER 3. SOFTWARE ECOSYSTEMS
27
some degree of consensus, because leadership is possible only when others
agree to follow” (Cusumano and Gawer, 2002). On the other hand in Class
2 environments, the central (or key) organization is created and controlled
by the organizations in the system. Class 3 environments present no central
organization.
Hanssen reports that Trists describes these ecologically oriented systems
as “lacking a formal structure” (Hanssen, 2012), “exist[ing] through the use
of technology” (Hanssen, 2012)’ and based on shared values. Regarding this
last characteristic Hanssen states that Trist makes a parallel with the youth
culture of the 60’s having a clear set of political values but not a formal
organization. A more business oriented parallel can be made with growth
and profit being the shared values (Hanssen, 2012).
The particular challenge is that organizational ecosystems are difficult
to recognize, understand and describe due to their weak structuring; this is
more difficult to achieve than for example smaller-scale systems like single
organizations or larger-scale systems like societies (Hanssen, 2012). Software
ecosystems belong to the intermediate level category; organizational ecosystems. Therefore software ecosystems can be described with the aid of Trist’s
theory of organizational ecology, being this theory concerned with “...organizations operating in complex and unstable domains.” (Hanssen, 2012).
Consequently, based on Trist’s organizational ecology, Hassen (Hanssen,
2012; Hanssen and Dybå, 2012) lists theoretical propositions regarding SECOs.
Before presenting this theory, we have to report that the author is concerned
with a particular type of organizational environment. Hanssen’s case study
is concerned with a Class 1 organizational environment, according to Trist’s
classification; named keystone-centric software ecosystem (Hanssen, 2012).
The setting of the case study is a software company that has recently
decided to open up its successful product line, and adopt a software ecosystem strategy. For the objectives and concerns of this master’s thesis this is
satisfactory. However, it seems legit to argue whether this theory, and the
characteristics of SECOs it lists, holds if applied to other kinds of software
ecosystems. Further information on taxonomy regarding software ecosystems
can be found in the following section.
The theoretical propositions are:
1. The organizations in a software ecosystem refer to a central
organization, and are linked to it by interface relations.
As in the study presented by Hanssen, the study setting is such an
organization, and according to Trist’s classification it belongs to Class
1. The central organization does not control the other organizations
CHAPTER 3. SOFTWARE ECOSYSTEMS
28
but it controls the software platform which affects all the activities in
the ecosystem.
2. “Software ecosystems promote self regulation” (Hanssen, 2012).
In the specific case study it is noticed how the development of the
software platform, previously a product line controlled in a centralized
way, is now a collaborative approach where the central organization
adapted to its central environment and vice versa. This can be seen as
self-regulatory behavior.
3. “Software ecosystems have a networked character” (Hanssen,
2012).
In this case study the network consists of customers and third party organizations. Also competitors might be considered part of the network,
though the author acknowledges it is only an insight.
4. “Software ecosystems exist through the use of information
and communication technology ” (Hanssen and Dybå, 2012).
Technology concerns not only the software platform that constitutes
the foundation of the software ecosystem, but also the of tools that
enable collaboration among different actors.
5. The participants in a software ecosystem share values (Hanssen,
2012).
In the specific case study the value is the software platform. This value
translates into licensing and services for the keystone organization, the
customer benefits for improved business operations while third-parties
sell solutions on top of the product line that has become a software
platform. The shared value provides the motivation to contribute in
the software platform.
After these initial five points Hanssens’s article (Hanssen, 2012) presents
also:
1. “The shared value of a software ecosystem is both the software
product and the business domain” (Hanssen, 2012).
In this study Hanssen observes how the keystone organization is interested in the business served by the product line, besides obviously
the product line. In the same way the customers become interested in
the technology driving their business. This is a result of the proximity
with the external environment and the increased permeability of the
organization borders.
CHAPTER 3. SOFTWARE ECOSYSTEMS
29
2. Software development is a shared responsibility between the
keystone organization and the external actors.
There is a shift of control toward third-parties and customers. This
happens because the product line’s, now software platform, processes
are opened to external actors, together with the visibility of plans and
strategies. These are other motivators for collaboration and affect positively all the actors of the ecosystem.
3.4
Taxonomy of Software Ecosystems
As we just pointed out, Hanssen’s theoretical framework bases its evidence on
a keystone-centric software ecosystem. That is precisely what this master’s
thesis is concerned with. However there are other possible typologies of
SECOs.
There are various ways in which to classify the different ecosystems. In
this section we present three taxonomies we found in the literature. The
first one presents a two dimensional taxonomy of software ecosystems (figure
3.1). The first dimension determines the abstraction level the ecosystem
operates at, while the second dimension indicates the computing platform,
and also the degree of evolution of the industry the ecosystem belongs to
(Bosch, 2009). The dimension named “category” (Bosch, 2009)includes the
operating systems, application, and end-user programming levels; while the
three considered platform types are: desktop, web and mobile. The author
of this taxonomy tries to put a stress on the fact that although SECOs have
recently attracted increasing attention in the mobile and web 2.0 context,
other types of software ecosystems already existed around desktop operating
systems; Even videogame consoles are a valid example of SECOs.
The same author provides also another categorization, this time based
on the different examples provided by the articles in the special issue of
the Journal of System and Software (Vol. 85) he introduces. As illustrated
in figure 3.2, the examples range from ecosystems created around a product
line opened-up for third-party development, to open-source platforms around
which raises a community of actors having different classes of roles (Bosch,
2012). Bosch (Bosch, 2012) introduces the degree of freedom and control
as an additional dimension for distinguishing software ecosystems. In this
sense different ecosystems have different ways in which the platform and
third-party development is driven.
The last taxonomy stems from our understanding of Trist’s theory on
organizational environments, as it is presented in Hanssen’s paper (Hanssen,
2012). Dividing the different SECOs into classes, we list:
CHAPTER 3. SOFTWARE ECOSYSTEMS
30
Figure 3.1: The Figure illustrates a way of organizing SECOs in terms of
category and platform domain. Source: Bosch (2009)
Figure 3.2: The Figure is visualization of a two-dimensional space where a
SECO could be placed according to its characteristics. The visualization is
based upon Bosch (2012)’s description
CHAPTER 3. SOFTWARE ECOSYSTEMS
31
• Class 1: is denominated Keystone-centric software ecosystem. There
is a keystone organization that controls the software platform and the
other organizations are linked to it by interface relations. To this
class belong the almost all the famous commercial SECOs (eg. Android ecosystem, Apple ecosystem, Windows phone etc..). Many other
companies are undergoing a transformation process, like the company
studied in the longitudinal case study by Hansen (Hanssen, 2012). This
transformation process typically happens in a way that a successful software product line is opened up, in the simplest way, providing APIs in
order to pursue a SECO strategy.
• Class 2: This class of SECO has a central organization that the other
organizations refer to, however the central organization is “brought in
to being by the member organizations rather than being one of the key
constituents” (Hanssen, 2012). As an example that could fit in this
category we could bring the SECO existing around the Eclipse foundation (Jansen et al., 2012). The Eclipse project is a collection of tools
to support software developers in building software (libraries, compilers, IDE etc.), its first version was released as open source in 2001 by
IBM, in the same year nine companies created a consortium that now
is an ecosystem with tens of thousands of developers, strategic members and other categories of members such as enterprise and associate
members. The foundation is non-profit and member-supported, and
it has the function of providing governance services. Differently from
opensource communities the Eclipse foundation has more or less the
organizational structure of a company. Addtionally, developers need
to go through a specific legal process when committing code (Manikas
and Hansen, 2013).
• Class 3: This class of ecosystem does not have a referent organization;
it has its own particular structure. An example of this class of ecosystems can be the open source communities existing around the many
distributions of the Linux operating system; for example the community around the Debian distribution of Linux. As a basis of these
ecosystems there is a platform constituted by Free/libre/open Source
Software (FLOSS) (Kilamo et al., 2012). Such open source communities are structured in a so called “Onion Model” (figure 3.3), where
the members are layered according to the level of participation in the
development and the level of influence they have on the project. In the
middle of the onion there is the project leader and at the external layer
we find the passive users. In addition to that Kilamo et al. specify that
CHAPTER 3. SOFTWARE ECOSYSTEMS
32
Figure 3.3: The Onion Model for open source communities. Source: Kilamo
et al. (2012).
this onion model does not depict the entire ecosystem, but there are
also industrial partners and other interest groups that are not present
in this model.
3.5
Roles in Software Ecosystems
Relations are a fundamental part in the description of SECOs, going back
to the definitions presented at the beginning of the chapter, it is possible
to observe how already in the first part of his definition Jansen emphasizes
the importance of the relationships among the different actors in a SECO
(Jansen et al., 2009b). In their literature review Manikas and Hansen remark
upon the importance of the social aspect within SECOs, stating that the
interactions between the different actors have an impact on the software
architecture [21]. In fact, different concerns from proprietary platforms need
to be taken into account: management processes; business models and IPR
issues getting more complicated; the evolution of the system being a lot faster
and potentially taking different directions.
For example the definition by Bosh and Bosh-Sijtsema individuate three
central roles: the software platform organization with his internal developers, the external developers and experts providing services and finally the
community of users. Also Hanssen in his article individuates the same three
types of roles, though using a slightly different terminology. Hanssen presents
a list that includes first, what he refers to as the “keystone organization”;
CHAPTER 3. SOFTWARE ECOSYSTEMS
33
this organization is the one responsible for the development and governance
of the software platform (Hanssen, 2012). Regarding the keystone organization, Jansen makes an interesting parallel: borrowing the concept from
biology, the keystone player is a species that plays a fundamental for the
ecosystems health “without being a significant position of the ecosystem itself” (Jansen et al., 2009a); like for example the jaguar, whose hunting keeps
the mammalian number in balance in the jungle ecosystem. The second role
is the end-user of the software platform (and additional services) that need
it for whatever task they need to accomplish; In the context of SECOs endusers have an active role and a selective approach (i.e. they are not passive
consumers), as reported in Bosch’s and Bosch-Sijtsema’s definition “...compose...solutions...to satisfy their needs” (Bosch and Bosch-Sijtsema, 2010b)
(Bosch and Bosch-Sijtsema, 2010a). The third role is played by the “thirdparty developers” that can belong to so called third-party organizations and
use the resources offered by the software platform to produce additional solutions and services.
These three roles that were just presented constitute the basic set. However other roles are suggested to be considered in the context of SECOs. For
instance Hansen lists also competitors (i.e. competing SECOs), standardization organizations, resellers and telecom operators (Hanssen, 2012). These
last ones are particularly relevant to the SECO under examination in this
Mmster’s thesis, but are left out of the scope of this work.
Yet another perspective is offered by Jansen et. al (Jansen et al., 2009b),
according to whom at a “software vendor level” (Jansen et al., 2009b) actors are linked to each other forming a “software supply network (SSN)”
(Jansen et al., 2009b) and categorized into: end-users, suppliers, and resellers. Manikas and Hanssen refer to those roles as, respectively: customers,
producers and integrators using the terminology from Sacchi and Alspaugh
(Scacchi and Alspaugh, 2012).
Manikas and Hanssen in their review (Manikas and Hansen, 2013) collect
and compare the different roles mentioned in the different articles constituting the literature body. These roles are grouped according to similarity, being
that the different authors of the reviewed articles have used different denomination for the same function within SECO. Manikas and Hanssen provide a
list that is summarized in the table 3.5. The Table presents the roles listed
in the literature review (Manikas and Hansen, 2013), the ones we selected in
the context of this master’s thesis, and a brief description of the roles.
The table includes also the roles that we decided not to consider in this
Master’s thesis. Additionally, we do not consider it interesting to map the
roles and the articles they have been found in. We simply want to highlight
that depending on the article a subset of this role is used; in fact the roles
CHAPTER 3. SOFTWARE ECOSYSTEMS
34
presented in an article depend much on which is the research focus and
what is the study setting (i.e. which kind of SECO). For example software
ecosystems existing around open source communities have different roles and
organization, as can be noticed the briefly introduced onion model in figure
3.3.
In a simplified view of the topic, considering SECO as two-sided markets
(Cusumano and Gawer, 2002), we have one side the end-users and on the
other side the third-party developers that develop and market (depending
on the type of ecosystem) solution for them. the relationship between endusers and third-party developers is somehow supervised and controlled by
the keystone organization, being such a relation mediated by the software
platform. Also the relation between the keystone organization and the thirdparty developers is mediated by the software platform; specifically by the
platform’s resources that effectively allow the third-parties to develop additional solutions on top of the software platform. As it can be deduced by the
introduction Chapter, this Master’s thesis focuses on the relation between
the keystone organization and the third-party developers.
CHAPTER 3. SOFTWARE ECOSYSTEMS
35
In this master’s thesis
Keystone (organization,
player)
Literature Review
Description
Company or unit or department
of an organization responsible for
the development and governance
of the software platform.
-
Orchestrator,
keystone (player, organization), hub, shaper,
management
(unit)
and platform owner
Niche player, influencer or component
developer/
builder/
team
The actor that complements the
role of the keystone player by
developing additional functionalities to the software platform. It
does not belong to the three basic roles presented in the beginning of this section. For simplicity, be assimilated with the keystone (player, organization).
External actor, exter- The actor (can belong to thirdnal developer (team), party organizations) that uses
third party developers, the resources offered by the softexternal parties/ part- ware platform to produce soluner/ entities, partici- tion and services upon it.
pant
Vendor,
indepen- Company or business unit sells
dent software vendor products to the end users of the
(ISV), reseller or SECO. It does not belong to
value-added reseller the three basic roles presented
(VAR)
in the beginning of this section.
This software vendors can be assimilated to third-party organizations, and we regard them as the
entities concerned with business
models and IPR issues. They are
scoped out of this Master’s thesis.
Customer, end user
Person or Entity that composes
solutions for itself on top of the
software platform.
Third-party
developer
-
End-user
Table 3.2: Summary of the roles actors can assume in SECOs. In the first
column there are terms used in this master’s thesis, in the second the different
terms found in the literature review (Manikas and Hansen, 2013)
Chapter 4
Third-Party Development
in SECOs
When companies, starting from a software platform, decide to enact a software ecosystem strategy and become platform leaders, they face business
and technological challenges (Gawer and Cusumano, 2008). As remarked
when defining the scope of this thesis, our focus is on technological challenges within a keystone-centric software ecosystem. The key technological
challenge is designing the proper architecture for the software platform so
that it enables third-parties to provide complementary assets(Gawer and
Cusumano, 2008); ultimately, this is achieved by designing interfaces and
connectors for complementary software applications. Keystone players have
the role of industry enablers, they have to sacrifice some interests and invest
in helping others innovate on the platform for a common good (Cusumano
and Gawer, 2002). This means investing in many different ways to facilitate
third-party development. After all, as we said in the previous chapter, there
is a symbiotic relationship between the actors of a SECO and the SECO
itself, a thriving ecosystem offers potential benefits to all; given that one is
able to harness them.
4.1
Software Platforms
There are many kinds of platforms, as we mentioned when discussing the
background, from the industrial economics point of view they are generally
seen as two-sided markets. Different platforms have different characteristics
and different business contexts. Ghazawneh (2012) discusses the categorization offered by Gawer: “Internal Platforms” are found within product development inside a company, and consumer electronics offers various examples;
36
CHAPTER 4. THIRD-PARTY DEVELOPMENT
IN SECOS
37
“supply chain platforms” expand the previous concept involving partners
along the supply chain; finally, “industry platforms” or “external platform”
serve as a base for other companies to build complementary assets in the form
of services or technologies, and these assets are not part of the supply chain.
Often industry platforms are found in the context of software development
(Cusumano and Gawer, 2002; Ghazawneh, 2012).
In general, platforms have modular architectures to achieve reuse and
variety (Baldwin and Woodard, 2008). Meaning that the core has low variety,
whereas the complementary components have high variety; conversely, the
complements have low reusability while the core has high reusability. Among
the advantages of using platforms there are: the realization of an economy of
scale(Ghazawneh, 2012); addressing the different needs of an heterogeneous
customer base, as we already described in the introduction to this master’s
thesis.
4.1.1
Software Platforms Architecture
Software systems, often have modular architectures. In modular architectures
the different modules interact together through interfaces (Messerschmitt and
Szyperski, 2003). Basically, these interfaces provide instructions to the other
modules about how to use a specific module. Strictly speaking, the interfaces
specify a series of actions; these actions expect some precise parameters as
input and return some precisely formatted data as output once the action is
invoked. Protocols are collections of actions (Messerschmitt and Szyperski,
2003) and accomplish more complex functionalities.
Digital technology is also characterized by a layered architecture, and the
most immediate example is the Internet (Yoo et al., 2010). Following an
illustration provided by Yoo et.al (Yoo et al., 2010) based on the work of
Benkler, and Farrell and Wiser we can individuate four main layers. These
layers are, from the bottom, a device layer, a network layer, a service layer
and, at the top of the stack, a content layer. These layers appear to be a
simplified and more conceptual version of the open system interconnection
model (OSI, ISO/IEC 7498-1). Anyhow, the underpinning idea is that those
layers belong to different design hierarchies(Yoo et al., 2010). Thus, within a
layer “...design decisions for components...can be made with minimum consideration of the other layers”(Yoo et al., 2010).
A “...layered modular architecture is a hybrid between a modular architecture and a layered architecture...” (Yoo et al., 2010). A layered modular
architecture is not tightly bound to the product(Yoo et al., 2010); thus in
designing components only little product-specific knowledge is required, differently from a modular architecture. Layered modular architectures are
CHAPTER 4. THIRD-PARTY DEVELOPMENT
IN SECOS
38
defined as being product agnostic (Yoo et al., 2010). Layered modular architectures are typical in the case of the software platform within SECOs since
they enable third party development.
4.1.2
Platform Boundary Resources and Third-party
Development
In the previous subsections we introduced interfaces as a means to glue together the modules in a modular architecture. Interfaces are also useful for
developers that want to build additional modules, so they can for example
invoke action on some third-party module and just use the results. Potentially, invoking an action could generate a chain of many calls, having the first
invoke the second, and so on. This is called encapsulation (Messerschmitt
and Szyperski, 2003).
Through encapsulation two objectives are achieved. First, developers
don’t need to know lower level details and their job is simplified. Second, the
implementation details are not exposed, which is good for security concerns.
Interfaces are regarded as open when they are: “available, well documented, and unencumbered by intellectual property restrictions” (Messerschmitt and Szyperski, 2003). There are different degrees of openness, depending on the type of licensing. More specifically, we use the term Application programming interface (API) when an open interface is extensible with
other modules even after deployment (Messerschmitt and Szyperski, 2003).
What has been just described for a modular architecture holds also for a
layered modular architecture. Nevertheless there are some peculiar characteristics. Google Maps is offered as an example to illustrate the previously
described characteristics of modular layer architecture (Yoo et al., 2010).
Google Maps can be used as a standalone product giving contents, in the
form of maps, and services, in the form of search, directions and commercial information. However, it also offers interfaces at the different service
layers, so that Google maps services can be integrated with other software
applications, developed by third-parties and/or internal developrs, hosted on
various kinds of devices (Yoo et al., 2010).
In the same way, Facebook can be used as an on-line social networking application (Kaplan and Haenlein, 2010) with all its related functionalities. At
the same time, third-party developers can create applications hosted within
Facebook’s web application or access Facebook’s services through external
applications functioning on different devices.
This particular nature of layered modular architecture makes the design of
components different. The design process is an orchestration of components
CHAPTER 4. THIRD-PARTY DEVELOPMENT
IN SECOS
39
from different layers, thus belonging to different design hierarchies (Yoo et al.,
2010). In this contexts, the designers of the components cannot completely
predict how the component will be used (Yoo et al., 2010). So Facebook’s
and Google’s designer cannot fully predict which kind of new software application can be created and in which new ways these applications can make
use of the different components. Here lays the generativity: “a technology’s
overall capacity to produce unprompted change driven by a large, varied,
and uncoordinated audience” (Zittrain, 2006); thanks to which innovations
can spring at any layer.
In both the Facebook and Google examples, the extensibility beyond the
standalone product is, ultimately, technically possible because of the APIs.
The extensibility of the software platform in SECOs was already discussed
in the previous chapter, but the APIs were not further described. As explained in the beginning of this Section, APIs are a particular kind of interface (Messerschmitt and Szyperski, 2003). Specifically APIs are composed
of public classes, their methods and interfaces, often packaged in software libraries and provided with the related documentation (De Souza et al., 2004).
The API itself is an interface and it is public, while its implementation is
a specification of how to interact with a software component and is private
(unless the source code it is available, like in FLOSS); in many cases the
software component is part of a platform. The public interface is used by
the API consumer (De Souza et al., 2004), that is the third-party developer
in the context of SECOs. The implementation is developed published by the
API producer, that is the key-stone player in the context of SECO. On an
abstract level we can say that that an API is an interface between two worlds
(De Souza et al., 2004).
An important feature of APIs is stability. In fact the first role that
De Souza et al. (2004) assign to the APIs is the role of a contract between
the API producer and the consumer. Meaning that there is a trust-based
relation between the API producer and consumer (Ghazawneh, 2012): The
producer describes the functionalities of the API and ensures that the API
works as promised; in that way the consumer trusts the producers and creates applications based on that functionality. In this way both parties can
work asynchronously and minimize coordination efforts. The basic principle
behind this, is that the API consumer’s code relies on the producer’s code
and expects that code to not change often (De Souza et al., 2004); or at
least that the changes don’t affect much the consumer’s code. This is what
stability means and what is expected by the API producer. Conversely the
API consumer has to find the right ways to interact with different software
components (Ghazawneh, 2012).
The second role is the organizational boundary (De Souza et al., 2004).
CHAPTER 4. THIRD-PARTY DEVELOPMENT
IN SECOS
40
An API is designed to provide access to a particular software component,
so it is conceptually at the external boundary of that component. If the
software component is part of a software platform then the API also defines
one of the external boundaries of the platform. As a boundary, the API,
allows to whom controls the platform, namely keystone player in a SECO,
to define the limits of what the API consumers, need to know and can do.
4.2
Platform Boundary Resources
APIs have been mentioned since the Introduction chapter. They were mentioned when talking about the resources of a software platform that are necessary to harness the benefits deriving from attracting third-party development
and create a SECO. The benefits are the potential for generativity derived
by heterogeneous actors creating heterogeneous and unexpected components
(Yoo et al., 2010) that, ultimately, spark positive cross-side network effects.
APIs, though, are not the only resources that are provided to thirdparties. According to Ghazawneh (Ghazawneh, 2012) those resources are
referred to as platform boundary resources and organized in two classes:
Technical boundary resources. In order to enable third-party developers to build complementary software applications on top of software
platforms, keystone players provide software development kits(SDKs).
The most streamlined version of an SDK can be constituted by a series
of APIs and related documentation. In other cases third-party developers can be provided with fully integrated development environments
(IDE) like Visual Studio1 for the different software platforms offered
by Microsoft Corporation2 or extensions for already existing IDE, like
Android extensions for Eclipse3 . Someone might indicate with the term
SDK, the whole package of resources that is given to third-party developers; what we actually describe as platform boundary resources. We
see the SDK as the resources given to the third parties that provide
technical feasibility to the development of complementary application.
Social boundary resources. Proprieties that make software successful are
often a result of understanding the needs of the end-users, and realizing in an “...efficient, natural and even enjoyable way.” (Messerschmitt
and Szyperski, 2003). In fact, creating good software requires “...strong
1
http://www.microsoft.com/visualstudio/eng
http://www.microsoft.com/
3
http://developer.android.com/tools/sdk/eclipse-adt.html
2
CHAPTER 4. THIRD-PARTY DEVELOPMENT
IN SECOS
41
connection with all the stakeholders...not only users but managers, administrators ...and others” (Messerschmitt and Szyperski, 2003); So
“creating software is ultimately a highly social activity”(Messerschmitt
and Szyperski, 2003). We already mentioned that, one of the purposes
of the platform resources is to minimize the coordination effort needed
for the collaboration between the third-parties, that develop complementary applications, and the keystone player. So, since the platform
resources need to be an interface between these two worlds, a particular
set of platform resources are meant to transfer the knowledge of these
social aspects of creating software. These resources include incentives,
intellectual propriety rights (IPR), platform guidelines and documentation (Ghazawneh, 2012). Technical documentation about the APIs
maybe considered part of the APIs itself. In our opinion Social boundary resources also include: All the training material that the keystone
player may produce to facilitate and speed up the learning process of
the third-party developers; particular events that may be organized to
promote a particular SECOs among third-party developers and closer
contact and support is offered by the keystone player; or other means
of interactions like online community forums.
At the beginning of this section we listed the purpose; now we want to
present some ideas behind the use of platform boundary resources.
The generativity within a SECO is enabled by its layered modular architecture. However, the generativity to be completely accomplished needs
a new organizational logic, given that heterogeneous actors have their own
innovation strategies (Yoo et al., 2010). According to Yoo et al. (Yoo et al.,
2010) this new organizing logic is doubly distributed. In the first place, it is
distributed because “...the primary source of value creation is the generativity
that comes from the unbounded mix-and-match capabilities of heterogeneous
resources across layers” (Yoo et al., 2010). Secondly, it is doubly distributed
because control (Hanssen, 2012) and knowledge (Ghazawneh, 2012) are distributed and span beyond the borders of a single organization (Yoo et al.,
2010); because organizations are more permeable (Hanssen, 2012).
As already mentioned in the Motivation Section, the keystone player faces
a compromise. In order to harness the benefits deriving from such a doubly
distributed organization logic, the keystone player shifts design capabilities
to the third-parties, but this also means shifting part of the control (Hanssen,
2012) and sharing knowledge with the third parties. This generates a constant tension in the relationship between the keystone player and the third
parties(Bosch, 2009; Ghazawneh, 2012).
These dynamics do not happen exclusively around software platforms
CHAPTER 4. THIRD-PARTY DEVELOPMENT
IN SECOS
42
within SECOs. For example Von Hippel and Katz (von Hippel and Katz,
2002) brings examples within product development ranging from semiconductor manufacturers offering custom chip development to a food company
offering a Mexican sauce. In those cases the companies decided to shift design
capabilities to the end-users through design toolkits, ranging from computer
aided design (CAD) software to a set of ready-to-use ingredients, so that the
end-users can develop custom products. The idea behind it is that this spares
the manufacturer from understanding the user needs in detail. At a conceptual level these toolkits resemble the platform boundary resources described
in this section. Given that in any context is fundamental to understanding
customers’ needs. In the case of SECOs, as we see it, the keystone player
delegates the understanding of specific needs of heterogeneous end-users to
heterogeneous third-party developers. So we can make a parallel between
toolkits and platform boundary resources; meaning that at a general level
what holds for toolkits can hold for platform boundary resources.
As we expressed before for platform boundary resources, toolkits are interfaces between two worlds and a basic function is to share knowledge across
these two worlds. In the case of product development, the manufacturer holds
information related to the solution potential and production process while
the users have needs and context related knowledge (von Hippel and Katz,
2002). In the case of software ecosystems, the situation is a bit more complicated because we have an additional category of player. Nevertheless, we
can say that it is more probable that heterogeneous software developers are
at least closer to, and thus can understand better, heterogeneous end-users
than the keystone player. Meaning that a particular third-party developer
or organization is closer to a certain segment of end-users than the keystone
player can ever be to all the end-user segments.
To sum up, we can say that in the context of SECOs platform boundary
resources as a whole have the following roles: They ensure technical feasibility
of developing additional applications on top a software platform; they can
facilitate third-party developers in the software development processes; they
minimize the effort for coordination between the processes of the keystone
player and the third-party developers
4.3
Boundary Objects in Design
Previously, we expressed the conceptual similarity of Toolkits in product development and platform boundary resources in SECOs. Additionally these
two objects could be abstracted to a higher level concept. As Ghazawneh
(Ghazawneh, 2012) suggested, the resources exposed by a software platform
CHAPTER 4. THIRD-PARTY DEVELOPMENT
IN SECOS
43
in the context of a SECO can be seen as boundary objects, and consequentially can be referred to as platform boundary resources.
According to Ghazawneh (Ghazawneh, 2012) understanding boundary
objects provides a theoretical basis to understand the role of platform boundary resources in SECOs. The understanding starts from the theoretical
propositions on SECOs (Hanssen and Dybå, 2012), from which we know
that software development is a shared responsibility between the keystone
player and the third-party developers.
A boundary object is defined as an artifact or object with
enough structure to support activities within separate social worlds,
and enough elasticity to cut across multiple social worlds(Bergman
and Mark, 2007)
In a more compact form, boundary objects (Bergman and Mark, 2007):
• Are present in several social worlds,
• Are compliant with the institutional requirements of each social world,
• Are weakly structured in common use,
• Are strongly structured in local use.
Boundary objects and their proprieties have been studied as different kind
of artifacts from museums to engineering drawings to medical patient records
(Bergman and Mark, 2007). Boundary objects have been studied in relation
to how they coordinate activities across social worlds: For example configuration management systems to maintain the flow in software development
(Bergman and Mark, 2007); in the case of design artifacts, they have been
studied as design boundary objects(DBO).
More specifically, if thought of as DBO, boundary objects assume the
role of bridging the gaps in design knowledge and agreements (Bergman and
Mark, 2007). Meaning that, these design boundary objects are artifacts that
transfer knowledge about a particular designed system across two worlds, and
also align the interests of the different stakeholders present in those social
worlds (Bergman and Mark, 2007).
There are four important features of design boundary objects (Bergman
and Mark, 2007). First, they promote shared representation: functional
representations like data, architectures, prototypes and specification; also
political representations like agreements and contracts. Second, placing a
design boundary object between a provider and a recipient mobilizes and
CHAPTER 4. THIRD-PARTY DEVELOPMENT
IN SECOS
44
invites action. Third, the shared representation is refined as something more
specific as it moves from idea to solution. Fourth, the design boundary object
legitimates that the content of the knowledge being transferred aligns with
the interest of the stakeholders, so that the recipient can rely upon it.
At a general level, these properties align quite easily with what has been
said about platform boundary resources. To provide a few examples: Thinking of APIs as an interface between two worlds a contract between two parties
(De Souza et al., 2004); the platform resources allow the third-party developers to take actions; and the fact that there is a trust relation between
the keystone player and the third-parties, and they rely upon that to create
complement applications for the software platform.
Chapter 5
Third-Party Developer Experience
In the previous chapters we first hinted and then evidenced how crucial,
in the context of software ecosystems, third-party development is. As it
emerges from our research questions, we are interested in understanding how
the keystone player enables third-party development through a particular
design of the platform boundary resources, and also how this is perceived.
However, it appeared quite challenging to find and define criteria in relation to how third-party developers perceive the software platform and the
platform boundary resources; when using the boundary resources to develop
software applications. In our opinion, the challenge resides in the fact that
software platforms are also software products, but besides the possibility of
being used as standalone products, they offer third-parties with the possibility of developing complementary software applications on top of the platform.
So in a sense, software platforms may still be evaluated using the traditional
and standardized criteria for evaluating software, usability and user experience; on the other hand those criteria may not fit or may not fit completely
the purpose
Additionally, it has been quite hard to find specific reference to the topic
from the existing literature. One of the issues encountered while searching was also related to terminology issues; for example the term developer
experience can be mistaken with how experienced the developers are.
Nevertheless, we had to use some references as a starting point. So, under the guidance of an expert in the domain of usability and user experience,
we decided to use some standards on which to base our understanding. We
adopted the approach of picking the elements of those standards that seemed
to be adequate in our research focus. We selected ISO/IEC 9126-1 on software quality, and the ISO 9241 on ergonomics of human-system interaction.
45
CHAPTER 5. THIRD-PARTY DEVELOPER EXPERIENCE
46
The ISO 9241 was considered in its part 11 on usability and part 210 on
human-centred design for interactive systems, usually known for the definition user experience. We also used some concepts from part 110 (replacing
part 10) on dialogue principles, because all the previously cited standards
contain references to it.
Following the expert opinion, we assumed that the standards are sufficiently abstract to fit the purpose. In fact, in all the standards is stated
that all mentioned criteria, that we can call heuristics, are to be considered
in relation to specific users and specific context of use. Thus, the additional
step required is to reconsider the heuristics in relation to particular users and
context: In this case third-party developers in a keystone-centric SECO.
5.1
Quality Characteristics and Quality in Use
(ISO/IEC 9126-1)
The standard ISO/IEC 9126, as introduced before, is concerned with the
evaluation of software quality. In its Part 1 it provides a model for assessing
software quality in terms of internal and external quality and quality in use.
The standard first presents a list of characteristics and subcharcteristics that
can be measured by internal and external measures; which in turn determine
internal and external quality. After that quality in used is described.
5.1.1
Relation to Third-Party Developer Experience
Internal quality gives an internal view of software quality. As it is presented
in the standard, it does not seem that internal quality can describe the perception of the system of third-party developers. Issues related to the internal
quality do certainly have an impact on third-party developer experience, but
those issues are mainly related to internal quality requirements.
External quality, on the other hand, is measured through testing in simulated environments and using simulated data. In this case, the issue would
be the applicability to platform boundary resources; maybe the approach
could work with UI elements of IDEs and to only some extent with APIs.
How we see the problem is that, tests are usually targeted at a specific set
of use cases. However, as we explained in the previous chapter, software
platforms typically have a layered modular architecture, and the designers
of some module cannot fully predict which new software application will be
crated on top of the platform; or in which way these applications will interact
with external services.
CHAPTER 5. THIRD-PARTY DEVELOPER EXPERIENCE
47
Further more, also the standard ISO 9241-11 raises similar issues. The
standard, in its Annex D, argues against ISO/EIC 9126-1 that usability issues cannot be tested in isolation; because usability is not an inherent characteristic of the software, it is a capability of use in a particular context by
a particular user. It must be acknowledged though, that ISO/EIC 9126-1
(Section 6.3.3) specifies in Note 3 to its section on operability that “For a
system which is operated by a user” quality in use can be used as a measure of
external quality for a “combination of functionality, reliability, usability and
efficiency”. Where quality in use has a definition very close to the definition
of usability in ISO 9241-11.
Regardless of how they are being measured and the considered point of
view, some of the heuristics presented in this standard, meaning the characteristics and subcharacteristics of internal and external quality, seem interesting criteria within our research focus; except for the fact that they always
refer to a “software product”. The heuristics we selected, excluding the one
regarding basic functionality, are:
Usability in ISO/IEC 9126 concerns mainly the possibility for the software to be understood, learned, used and be attractive to the user, under
certain conditions.
Understandability is about the capability for the user to determine how
the software can be used to fulfill some tasks in certain condition. So, to
determine how much does the software help in achieving certain goals.
Perhaps a third-party developer, being different form an average user
of software, would be more concerned with the “analysability” of the
software. The meaning of the term in ISO/IEC 9126 will be explained
later.
Learnability is expressed simply as the capability to learn the application of
a software product. On this point ISO/IEC 9126 borrows ISO 9241 part
10 (now replaced with part 110) on dialogue principles. In this sense,
learnability corresponds to “suitability for learning” On this account
ISO 9241-110, among other recommendations, suggests that the user
should be able to access rules and underlying concepts; so that the
user can use its own reasoning to memorize activities, and, we add,
understand functionalities. 9241-110 also remarks upon the importance
of feedback in building an understanding of the system. Moreover, the
feedback should be not only about the final result of an activity but
also about intermediary steps.
Operability expresses concepts related to capability of the software to let
the user operate and control it. This concept is linked with controllabil-
CHAPTER 5. THIRD-PARTY DEVELOPER EXPERIENCE
48
ity, error tollerance and conformity with user expectations as described
in ISO 9241-110. The controllability principle goes into details that are
very “interactive dialogue”-specific, but at a general level it is about
controlling the direction of the interaction up to the point at which the
goal is achieved. On error tolerance the most remarkable point is that
explanations should be provided to the user to facilitate correction. Besides assisting in avoiding errors, the standard calls for actual means to
prevent the user from committing errors and causing unwanted effects.
Conformity with expectations is said to be the alignment of predictable
contextual needs of the user and accepted conventions. The interactive
system should use the vocabulary which is familiar to the user in the
performance of the task, or one which is based on the users’ existing
knowledge. Also data structures and forms of organization should be
thought in terms of what feels natural for the user.
Efficiency is about the resulting performances in relation to the resources
used, in certain conditions. Besides software and hardware resources, we suggest that for third-party developers, resources could mean cognitive effort,
amount of prerequisite knowledge required, and also time invested for learning or understanding how to accomplish a certain task.
Maintainability describes how modifiable a software product is. We
regarded it as interesting for its subcharacterisitcs.
Analysability in ISO/IEC 9126 is described in a way that does not fit, in
our opinion, with third-party development experience. However the
term itself seems quite interesting as an extension of the subcharacteristc “understandability”. In our view analysability is: the capability of
the platform boundary resources to be analyzed in order to assess the
capability of the software platform in terms of achieving the developer’s
vision and achieve specific tasks. We feel that the term understandability would be too superficial for a third-party developer that uses
the platform boundary resources as a working tool.
Stability in APIs and other platform boundary resources is an important
characteristic. In fact platform boundary resources constitute, as said
for APIs, an agreement between the keystone player and the third-party
developers; and the trust relationship is based upon this agreement. In
the case of platform boundary resources, the key is that despite internal
modifications, what is exposed to third-party developers remains as
stable as possible.
CHAPTER 5. THIRD-PARTY DEVELOPER EXPERIENCE
Characteristic
Usability
Efficiency
Maintainability
49
Subcharacteristic
Understandability
Learnability
Operability
Analysability
Stability
Table 5.1: A synthesis of the characteristics and cubcharacteristics of the
software quality model (ISO/IEC 9126-1) that we deemed most relevant for
third-party developer experience in a SECO.
The last part of the quality model in ISO/IEC 9126 Part 1 concerns
quality in use. Quality in use is described in a very similar way to usability
in ISO 9241 part 11. Therefore the discussion on the topic is postponed to
the discussion of ISO 9241-11. In relation to usability as described ISO/IEC
9126-1, quality in use has a broader meaning. in fact it can be affected by all
the characteristics that affect internal and external quality; also the ones we
have not introduced like functionality, reliability, and portability. However
it is stated that in this case the focus, as opposed to external and internal
quality, is on the result of the use of the software in a certain environment
rather than properties of the software. Quality in use is divided in four
characteristics, and the ones we selected are : “effectiveness”, “productivity”,
and “satisfaction”. Those are mapping the same criteria found in usability
(ISO 9241-11) the only difference being that productivity is indicated as
“efficiency” in ISO 9241-11.
5.1.2
Metrics from Software Quality
Regarding metrics of the software quality, we already discussed some issues
related to internal and external quality at the beginning of the section.
Concerning quality in use, ISO/IEC 9126-1 states that the measure is
about meeting the needs of specified users in achieving specified goals in a
specified context. The measure is expressed in terms of effectiveness, productivity and satisfaction (we decided to omit safety). The measure is not
concerned with the properties of the software but with the result of using the
software. However, it is said that those results are influenced by internal and
external quality; and internal and external quality are expressed in terms of
properties of the software, namely characteristics and subcharacteristics.
Depending on the type of user, the relationship between quality in use and
CHAPTER 5. THIRD-PARTY DEVELOPER EXPERIENCE
50
software quality characteristics varies. In this sense, the standard (ISO/IEC
9126-1) states that for end-users quality in use is mainly influenced by functionality, reliability, usability and efficiency, while for a person maintaining
the software quality in use is affected by maintainability. So quality in use
for third-party developers in a keystone-centric ecosystem could be affected
by the heuristics that we presented. Specifically the characteristics and subcharacteristics of the quality model described in ISO/IEC 9126-1 that we
highlighted in the first part of this Section.
Additionally, when discussing third-party software developer experience
there is, in our opinion, another issue to be considered. Third-party developers use and analyze the platform resources and the software platform itself at
a much deeper level than a normal software product user would do. So in our
opinion, it is hard to establish whether or not quality in use, for third-party
developers in a key-stone centric ecosystem, is only about achieving goals
with effectiveness, productivity and satisfaction. Or, since they have to use
the platform resources and the software platform as a tool and as part of their
own software applications, they are also concerned about the properties of
the software; meaning some of the quality characteristics and subcharacteristics expressed in the beginning of the section. Thus, there is a possibility
that their experience is also directly affected by those characteristics.
Finally, The ISO/IEC 9126-1 standard also reports that quality in use
is to be evaluated in specific user-task scenarios. This, as we argued in a
similar way for external quality, may not be sufficient. In fact in the context
of SECOs, it is difficult to predict which new software application will be
created and in which way the application will interact with the different
components of the software platform and external services.
5.2
Usability (ISO 9241-11)
The standard ISO 9241-11 defines usability and explains concepts related to
it which are necessary to take into account when specifying and evaluating
usability.
5.2.1
Relation to Third-Party Developer Experience
The standard states that its definitions concern visual display terminals,
but the definitions and explanations provided appear abstract enough to be
considered within our research objective. That means considering third-party
developers as users, and platform boundary resources of a keystone-centric
SECO instead of visual display terminals. Usability is defined as:
CHAPTER 5. THIRD-PARTY DEVELOPER EXPERIENCE
51
“The extent to which a product (a system or a service, as
added in ISO 9241-210) can be used by specified users to achieve
specified goals with effectiveness, efficiency and satisfaction”
and the components of usability are also defined:
Effectiveness as accuracy and completeness with which users achieve specified goals.
Efficiency as resources expended in relation to the accuracy and completeness with which users achieve goals.
Satisfaction as freedom from discomfort and positive attitude towards the
use of the product (a system or a service, as added in ISO 9241-210)
After the definition the standard puts an accent on specifying details
usability. The standard (ISO 9241-11) reports that there should be a clear
description of goals, which may be decomposed into subgoals. Accurate
descriptions should also be provided for the context of use; this translates
into description of relevant characteristics of users, of tasks necessary to
achieve a goal, of equipment and environment. Regarding tasks, often a set
of key tasks is selected to represent the overall task necessary to reach a goal.
5.2.2
Metrics from Usability
The standard ISO 9241-11 states that it is necessary to provide at least one
measure for each of the aspects of usability: effectiveness, efficiency, satisfaction. However it does not provide any rule about choosing the measure or
the level of detail of the measure. The standard gives only suggestions. For
example effectiveness could be measured in terms of mistakes in achieving a
task. Effectiveness is related to expenditure of resources, and the resources
can be measured in terms of mental effort, time or financial cost. Satisfaction
can be measured by defining scales for subjective measures like discomfort
experienced or the extent to which an objective has been met or simply the
number of positive and negative comments. These are just examples, and
as said before there is no general rule. To this end, satisfaction could be inferred by objective measures of user reaction or behavior and efficiency and
effectiveness can be estimated from the subjective opinions of the users.
The Annex B of ISO 9241-11 explores further the topic of measures.
Usability measures in terms of effectiveness, efficiency and satisfaction can
target the overall goal in using a software or, more practically, specific goals
within the use of the software. Additionally, the measures can also target
CHAPTER 5. THIRD-PARTY DEVELOPER EXPERIENCE
Usability Objective
Overall usability
Effectiveness
measure
Percentage
of
goals achieved
...
...
Meet the needs Percentage
of
to walk up and tasks completed
use
successfully on
first attempt
...
...
Learnability
Percentage
of users who
learned
the
criterion
...
...
52
Efficiency
measure
Time to complete a task
...
Time taken on
the first attempt
Satisfaction
measure
Frequency
of
complaints
...
Rate of voluntary use
...
Time to learn
the criterion (related to specified
efficiency level)
...
...
Rating scale for
ease of learning
...
Table 5.2: An example of usability objectives and possible measures for effectiveness, efficiency and satisfaction (source: Annex B, ISO 9241-11).
desired properties of the product that contribute to usability; and the desired
properties of the software can become usability objectives. To clarify these
statements it is better to provide an example coming from a table presented
in the Annex B, where there are examples of usability objectives and possible
measures in terms of effectiveness, efficiency and satisfaction. See Table 5.2.2
Going further into the relation between usability and the properties of the
software we can take learnability as an example. Learnability in ISO/IEC
9126-1 corresponds to suitability for learning in ISO 9241-110, which in turn
refers to the attributes of a product which facilitate learning. Actual learnability, as expressed in ISO 9241-11, in a specific “context can be measured
by comparing the usability of a product for one user over time”, like one of
the measures in Table 5.2.2, or “comparing the usability of a product for an
experienced and inexperienced user”. As stated for quality in use in standard
ISO/IEC 9126-1 the measure is about the result of using the software in a
specific context by specific users not about some intrinsic attribute of the
software.
In the end the measure depends on the objectives of those who performs
the measure, who have the task of choosing the measures and the level of
CHAPTER 5. THIRD-PARTY DEVELOPER EXPERIENCE
53
details. The validity of the data gathered will depend on how the user and
context of the measurement are representative of the real situation.
5.3
User Experience (ISO 9241-210)
The standard ISO 9241-210 is concerned with providing requirements and
recommendations for computer-based interactive systems using the principles of human-centred design. Ultimately the standard is interested in the
ways different components of interactive systems can enhance human-system
interaction.
5.3.1
Relation to Third-Party Developer Experience
The standard is particularly interesting, because of the concept and definition
of User Experience. It appears to us that this concept is quite general and
does not need to be modified in order to fit third-party developer experience.
User experience is defined as:
“Person’s perceptions and responses resulting from use and/or
anticipated use of a product, system or service”
The Note 1 to the definition clarifies that, besides perceptions and physical and psychological responses, user experience includes all the user emotions, before during and after use. For example satisfaction is heavily related
to emotions and physical and psychological responses; as described in ISO
9241-11. Satisfaction is also dependent on expectations; actually the expression “anticipated use” from the definition is commonly interpreted as the
expectation the user has of a product, system or service. A related concept
is conformity to expectations from ISO 9241-110 that is included in operability from ISO/IEC 9126-1 which is mainly about consistency throughout the
experience and using accepted conventions.
Additionally the Note 3 to the definition expresses that usability criteria
can be used to assess aspects of user experience. Meaning that usability,
when concerned with the users’ goals, includes the emotional aspects that
are part of user experience. In fact, as expressed in the previous section,
the choice of usability measures is flexible, as well as the choice of usability
objectives. Again, one may think that the aspects that emotional aspects
and physical and psychological responses pertain only to the satisfaction element of usability. However it very much depends on the usability objectives
one decides to measure and, as reported in ISO 9241-11, also efficiency and
effectiveness can be estimated from subjective opinions of the users.
CHAPTER 5. THIRD-PARTY DEVELOPER EXPERIENCE
54
The standard (ISO 9241-210), after providing definitions, describes principles and best practices of human-centred design. Within this description
the standard states that the designing activity addresses the whole user experience. Thus the design process needs to consider organizational impacts,
user documentation, support and maintenance in term of touch-points, training and long term use. Also aspects such as branding and advertising should
be considered.
These guidelines may translate in different ways when designing for the
user experience of third-party software developer in keystone-centric SECOs.
Some may be straight forward, like documentation; although the way documentation is structured and presented differs from the one targeting end-users
of typical computer-based systems. Other aspects, like brand and advertising, may translate into the offering proposed by the keystone player in terms
of market share, business models and IPR; or actually how are those perceived by third-party developers. Equally important thinking of the whole
experience, aspects of discovery, walk up and use, training, support and
maintenance may have different meanings and associated expectations than
for end-users of typical computer-based systems. So, despite conceptually
fulfilling the same function, those aspects may translate in different implementations to address the needs of third-party developers.
During the design process, design decisions draw a line between activities
that are to be accomplished by the user and the ones that are accomplished
by the system. In this sense the standard (ISO 9241-210) suggests that design decisions should be influenced by the knowledge of the user’s strength,
limitations, preferences and expectations. When relating this to the context
of SECOs, the line represents the division between the responsibilities of the
third-party developers and the ones of the keystone players. Such a division
of responsibilities is also a division between two social worlds and the platform boundary resources function as bridge. In the case of keystone-centric
SECOs, when designing the platform boundary resources, design decisions
are heavily influenced by the degree of freedom the keystone player wants to
give to third-party developers; in addition to the other aspects suggested by
the standard (ISO 9241-210). This is a consequence of the already mentioned
compromise between shifting capability and retaining control, and strategic
decisions (Ghazawneh and Henfridsson, 2011) that the keystone player has
to face.
5.3.2
Metrics from User Experience
Evaluation is given little space in ISO 9241-210 compared to the other topics.
However, evaluation is important from the earliest phases, due to the itera-
CHAPTER 5. THIRD-PARTY DEVELOPER EXPERIENCE
55
tive nature of human-centred design, and should be integrated in the design
process. The evaluation is used to obtain new information on user needs,
to assess that user requirements are met, to collect feedback on the current
design, or to make comparisons with other designs. In this sense we do not
see how the purpose of evaluation would differ in evaluating a software platform, particularly in its platform boundary resources, based on third-party
developer’s perspective.
Regarding the method of conducting the evaluation, ISO 9241-210 individuates two approaches: User-based testing and inspection-based evaluation.
We see user-based testing as more appropriate to evaluate third-party developer experience. This is based on the same rationale that was already used
when discussing external quality as presented in ISO/IEC 9126-1. In, fact
inspection-based evaluation relies on expert judgment, and may target expected use-cases.
However inspection-based evaluation could be used, as suggested in the
standard (ISO 9241-210), to complement user-based testing. In fact inspectionbased evaluation is quicker and simpler to fulfill.
Finally, the standard (ISO 9241-210) introduces long-term evaluation.
This means to collect feedback from the users over time, once the system is
deployed, to see if usability goals considering the whole experience are constantly met. We deem that continuous follow-ups are particularly needed in
the context of keystone-centric SECOs. As mentioned when discussing platform boundary resources and in this chapter, it is difficult to predict all the
possible ways in which third-party developers may use the platform resources
and interact with external services. At the same time, as the standard (ISO
9241-210) reports, external factors may change. Within SECOs, that translates to: those external services used by third-party developers may undergo
some changes, new legislation issues may raise, and some business models
may not be sustainable anymore. In our opinion the platform boundary resources should provide means to support assessment and collection of new
requirements in terms of the third-party developer experience.
5.4
The Standards and Third-party Developer Experience
The purpose of this chapter was to discuss how the selected standards can
provide basis for discussion in terms of third-party developer experience in a
keystone-centric SECO.
The different standards we considered have different objectives; though
CHAPTER 5. THIRD-PARTY DEVELOPER EXPERIENCE
Usability Ob- Effectiveness
jective
measure
Understandability some
selected
measure
Learnability
...
Operability
...
Analysability
...
Stability
...
56
Efficiency
Satisfaction
measure
measure
some
selected some
selected
measure
measure
...
...
...
...
...
...
...
...
Table 5.3: An example of the heuristics we selected from the software quality
model (ISO/IEC 9126-1) used as usability objectives. The Table is modeled
after the Table from ISO 9241-11 that we presented in the Usability section
ISO 9241-11 and ISO 9241-210 are closer to each other in their approach
than to ISO/IEC 9126-1. However, those standards refer to each other and
concepts that appear in different standards are interrelated. A possible approach is to select one of the standards and try to translate its guidelines
into the specific context of third-party development in a keystone-centric
SECO. Alternatively, another approach is to combine the elements of the
different standards that seem to better fit the context of our research work.
We decided to explore further the latter approach.
The standard ISO 9241-11 states that desired product properties can be
used as usability objectives. So an approach could be to use the heuristics
we selected from the quality characteristics of the quality model as usability
objectives; and then determine some measures in terms of effectiveness efficiency and satisfaction. A rationale is that ISO/IEC 9126-1 also associates
its quality in use with usability as expressed in ISO 9241-11 and states that
quality in use is eventually affected by the quality characteristics; if we exclude efficiency, that is one of the dimensions of usability. An exemplification
of what we just described is provided by Table 5.4.
Relating this to User Experience, the standard ISO 9241-210 expresses
in more than one occasion that usability has a much broader meaning than
what is commonly believed. ISO 9241-210 adds that usability measures can
be used to assess the whole user experience when the usability objectives
are concerned with the user’s goals. In this sense the main addition of ISO
9241-210 is a shift of perspective, where the usability objectives are explicitly
the user goals and those objectives are set for the whole experience.
CHAPTER 5. THIRD-PARTY DEVELOPER EXPERIENCE
57
There are different ways to estimate the user’s goals and select usability
objectives accordingly. In this case, one way could be using the heuristics we
selected according to the assumptions we made on the software quality model,
especially if the study has an explorative nature like this master’s thesis. The
process can be iterated to select better heuristics or more detailed ones; the
details can be specified according to specific SECOs or type of third-party
developers. After all, iterativity is a central concept in human-centred design
as described in ISO 9241-210.
Regarding evaluation and metrics, we have pointed out, across the discussion of the three standards, that user-based types of evaluations would
fit best in the case of third-party developers as users in the context of a
keystone-centric SECO. Especially regarding ISO 9241-11 and ISO 9241210, it is clear that the measurements are about the results of using a certain
software product, system or service. However we argued that, because of the
specificity of third-party development activity, third-party developers may
view the software platforms and its resources in a different way. Thus they
may also be interested in some of the quality characteristics; as pointed out
when discussing ISO/IEC 9126-1.
Chapter 6
Results of the Case Study
This master’s thesis is not only concerned with third-party development in
SECOs at a general level; we also study the problem in light of the practical
challenge that F-secure has to face.
F-Secure1 is a company that offers various security products, especially
antivirus software. More recently F-Secure has expanded its interests to
backing up, securing and managing, content from end-users. A result of
this new direction is Content Anywhere(CAN). CAN is a new born cloud
service offered mainly to telecom operators and their customers; a visual
representation is offered by Figure 6.1.
6.1
CAN Ecosystem
While the basic infrastructure of CAN had already been developed, originating from an internal tool, F-secure has more recently decided to enact a
software ecosystem strategy. This is done with the goal of proposing additional value to their customers (typically telecom operators) and end-users,
by means of additional content-centric services; meaning specific applications.
These applications are developed for various devices using device specific software and in the cloud using various kinds of web technologies. For doing so,
F-Secure offers a set of interfaces to the third-parties. To summarize, CAN
can be used as a standalone product, but it also provides interfaces that allow
integration to its services and other software components. Therefore it can
be assimilated to the examples provided when discussing SECOs’ software
platforms, and presents a layered modular architecture (Yoo et al., 2010).
The idea behind CAN Ecosystem is to offer a content-centric ecosystem
as a service. CAN Ecosystem is, in fact, a software platform designed in
1
www.f-secure.com
58
CHAPTER 6. RESULTS OF THE CASE STUDY
59
such a fashion that allows third-parties to build complementary applications
on top of it. In other words CAN is extensible beyond the borders of the
organization that operates it; using the definition from the previous chapters.
These third-parties developing applications can be the telecom operators
themselves, other companies or independent individuals.
Each and every instance of CAN Ecosystem is a software ecosystem of its
own. These CAN Ecosystem instances are similar and often share the same
physical resources, but each is controlled by a different telecom operator or
another entity, which has room for additional customization. This means
that each operator has a logical piece of the CAN software with separate
authentication and access. The basic idea behind CAN is that an end-user
can store his or her data in cloud storage. The security and privacy of the
data is ensured by F-secure. Then the data can be shared and accessed in a
secure way by other devices; as shown in Figure6.1. The supported devices
include mobile phones, computers, cameras and smart TVs and so on. That
means, technically any device able to install and run CAN’s client software.
According to the first taxonomy from Bosch (Bosch, 2009), presented
when discussing SECOs, any instance F-Secure’s CAN Ecosystem can be
placed in three slots of Figure 3.1. Regarding the category, a instance CAN
Ecosystem belongs to application level SECOs, whereas in terms of computing platform it covers all three possibilities. In fact, the end-user is provided
with a PC client, a mobile application and also a web interface; as you can
see from the top layer of the architecture picture (6.2).
Considering the taxonomy we created upon Hanssen (2012)’s classification, CAN Ecosystem belongs to a Class 1 software ecosystem and F-Secure’s
role in this particular SECO is the keystone player. Indeed F-secure has a
dominant position over the software ecosystem. To be exact it has control over many software ecosystems; we can consider each instance of CAN
Ecosystem as a separate ecosystem and the different operators as the various platform owners. So in this specific context we have a keystone player
(F-secure) and different platform owners (one for every instance of CAN
Ecosystem) that share control over CAN Ecosystem’s instances. As opposed
to what found in the literature and reported when describing roles in SECOs,
in this case the two denominations (keystone player, platform owner) cannot
be considered synonyms.
In its role, F-Secure faces the challenge of shaping CAN Ecosystem, in
such a way that can potentially result in a vibrant software ecosystem that
attracts third-party development, operators and end-users. This research
work focuses on the challenge of attracting third-party developers. In this
context, as explained when discussing the scope of this study, business and
legal issues a left out of scope and we concentrate on the software development
CHAPTER 6. RESULTS OF THE CASE STUDY
60
Figure 6.1: A visualization of CAN. It depicts the main functionalities of
CAN as a product. Source: F-Secure
experience using the resources offered by CAN Ecosystem.
6.1.1
Software Platform Architecture
As introduced before, CAN is a platform whose core functionality is to provide data in the cloud. Meanwhile it must ensure reliability, scalability
and security. Additionally, it needs to be possible to build complementary
content-centric services upon it. All these characteristics are reflected in the
architecture; a high level representation of these concepts is given in Figure
6.2. The architecture clearly reflects CAN’s primary role. A significant part
of the system is concerned with storing and retrieving the content in cloud,
the other significant part is managing the files. So, besides storing related
modules there are modules for synchronization and notification, sharing, and
securing. In order to aid the task of managing the files there are modules for
enhancing them by adding metadata and tags in “Workflow Management &
Workers”; this is fundamental for the functioning of the search module.
Metadata and tags can also be added to the content by end-users and
applications, that can then perform searching or filtering operations based
CHAPTER 6. RESULTS OF THE CASE STUDY
61
Figure 6.2: A high level representation of CAN’s architecture. It illustrates
the levels and the main conceptual modules. Source: F-Secure.
on those. Another module that can add Metadata and tags is “Custom
Worker”; although during the interviews has been referred to as “External
Workers”. This “External Workers” module has actually a more important
role, than just adding metadata. This module offers a means for the operator,
or platform owner in general, to extend the platform from the backend. For
example, once the files are uploaded to the storage component through the
content portal or other applications, some backend application can be notified
about that, do some additional processing on the file and upload it again to
the storage component.
As we can see from Picture 6.2 they are on a conceptually higher level
than “Custom Worker”/“External Worker” and are mainly concerned with
customizable elements at a client level. As explained at the beginning of this
chapter, each operator has a logical piece of the CAN’s software, which we
can call environments, and these logical pieces have a separate authentication
and access. F-secure develops CAN independently from the authentication
method of the operator.
The focus of the platform is also on the nature of the content. The
content of the end-users will be mainly multimedia files, therefore there are
already supported functionalities like streaming or creation of thumbnails to
provide some examples. Besides being content-centric, CAN is also deeply
user-centric. CAN is built in such a user-centred way that the only way of
handling requests using the APIs is by including a user key in the requests.
There is a basic assumption that mainly user action invoke these requests.
CHAPTER 6. RESULTS OF THE CASE STUDY
62
Figure 6.3: A representation of Content Anywhere Ecosystem: The software
platform, interfaces and complementary applications.
Another aspect that is not visible in this architecture picture, but it
emerged by interviewing the developers, is that CAN Ecosystem is actually
composed by three backends. These backends are: Part A, that is the actual
storage component; Part B is a service enabler backend, that accomplishes
licensing functions and contains information about user software assets; Part
C is a single sign-on authentication service. All these backends are reflected
in the software libraries that are part of the SDK provided to third-party
developers, and are also meant to be abstracted to a single backend. Meaning
that the libraries include specifications, of e.g. object classes and protocols,
that enable the interaction with the backends.
6.1.2
Platform Boundary Resources
This section provides an account of the resources that Content Anywhere provides to third-party developers. According to what explained in the chapter
CHAPTER 6. RESULTS OF THE CASE STUDY
63
on third-party development in SECOs, we refer to these resources as platform boundary resources and group them distinguishing technical and social
ones.
6.1.3
Technical Platform Boundary Resources
SDK As explained earlier in this thesis, SDK stand for software development
kit. In the case of CAN the SDK is mainly a collection of APIs. These APIs
are software libraries that allow the third-party software developers to interface their application with CAN’s services. These libraries are available for
different languages (C, C++, Python and Javascript), and offer equal functionalities in the way that is proper to the specific language. Conceptually
these APIs have two levels: The low level APIs are concerned with accessing
the functionalities offered by the three backends mentioned previously, meaning one API for each of the backends (Part A, B, C). Whereas the higher
level API, that is referred to as CAN API is meant to bridge together the
low level APIs providing a software library that is easy to use. The purpose
of these libraries is, indeed, to hide as much as possible the details of dealing
with the different functionalities of the different backends. A representation
of how the third-party components relate to Content Anywhere is provided
in Figure 6.3.
REST API The REST API (in Figure 6.3) presents the description of
the services exposed by the CAN Ecosystem platform. In other words it is a
description of the calls the platform exposes. To relate it with the previously
described SDK, the software libraries composing the SDK implement the
functionalities that are needed to access the REST API.
External worker It is essentially a backend API with its own libraries.
Thus, it represents another way to extend the CAN Ecosystem platform,
from the backend instead of the client side. It is meant for the platform
owner, typically operators, in order to further customize the platform in a
more efficient and “cleaner” way then they could do from the client side.
This API accesses CAN Ecosystem on a really low level, so it is critical to
decide to whom access is granted access.
6.1.4
Social Platform Boundary Resources
Developer portal The developer portal is the main reference for the thirdparty developers. Through the developer portal third-party developers can
download the necessary tools, namely CAN’s SDK, and access the documentation. The developer portal offers the main touch-point between F-Secure
CHAPTER 6. RESULTS OF THE CASE STUDY
64
and the third-party developers; in addition there are means of interactions
with other developers.
Conceptually the developer portal is divided into three areas. Besides the
possibility of signing up and logging in, The first area deals with documentation: From the fully blown documentation to less extended parts aimed
at getting a first impression and quick start development. The second area
is concerned with providing the technical boundary resources: Namely the
SDKs of the different supported programming languages. Finally, the third
area is meant for interaction with other third-party developers in the form
of a forum.
Registration As explained in the beginning of this chapter each instance
of CAN has a separate authentication and access. In order to abstract
the schema an operator might choose, it was decided to use Facebook
authentication. Having a Facebook account, the developer needs to
make a request and wait a for a confirmation e-mail. After that the
developer can register to the developer portal. Once the developer
gains access to the developer portal, he or she also gets an ID for the
application and two API keys. All these will then be included in the
applications being developed to perform requests on the can platform.
In this way it is possible to control how third-party applications access
the platform. Other companies use similar schemes e.g. Google and
Facebook.
Documentation The documentation can be considered part of the kit the
third-party developers get (SDK). However, it conceptually belongs to
the social platform boundary resources. CAN Ecosystem’s documentation essentially describes how the APIs work and provides an account
of different parts of the platform. The documentation also includes
chunks of code that provide exemplifications, as well as “hello world!”
examples. The documentation is divided in a part where there is an extensive description of the different APIs (in the different programming
languages) and another part with a more bootstrap-oriented approach.
Support The developer portal offers some basic means of interaction with
other third-party developers and the platform owner. These means are
e-mail contacts and a forum-like type of interaction.
Content portal It is a web application accessible through a web browser
where, after logging-in, an end-user can access and manage his or her content
on CAN. Besides guaranteeing a browser-based access for a end-user to his or
her contents, it was also a valuable debugging tool for the developers during
CHAPTER 6. RESULTS OF THE CASE STUDY
65
the hackathon. Through the content portal the developers could see the tangible effects of their operations on some test content. These operations range
from basic ones like uploading, to more advanced ones involving metadata
and tags.
6.2
Evaluation
After analyzing the data from the hackathon and the interviews we were able
to understand more about the CAN Ecosystem. We were also able to report
how the developers experienced the process of creating applications using
CAN Ecosystem’s platform boundary resources. In this section we report
our findings also providing some exemplifications. It can be denied that the
hackathon event also helped reporting some technical bugs. However, the
most relevant findings concerned high-level design decisions and the overall
developer experience.
Perhaps the most general evaluation of CAN Ecosystem is that it appeared to be targeting to a too limited set of use cases; this limited or anyways hindered other possibilities. As reported when describing CAN Ecosystem’s architecture, the platform is conceived in a very user-centred way; and
its basic interactions being a user storing and accessing personal data, by
means of conventional devices. So for example the platform had difficulties
supporting interactions with devices independent of humans or with devices
having limited means interaction. Providing some example: the authentication procedure of independent devices (e.g. a security camera) required
workarounds, or the interaction with a device without a keyboard (e.g. a TV
remote controller) was hindered.
This limited set of use cases follows the fact that CAN Ecosystem has
been designed from a very technical viewpoint. Hence, the basic functionalities of the platform were accomplished, but this happened at the expenses
of usability. In other words, the platform was technically adequate but the
hackathon revealed some issues regarding the experience of developing application using the platform boundary resources that needed improvement.
6.2.1
Understanding the Platform Architecture
At a general level it was reported by the developers that the overall picture
of the third-party API was somewhat difficult to grasp. While the basic infrastructure of CAN Ecosystem and its operations were easy to understand,
it was more challenging to determine how the different parts of the platform
were supposed to work together. Particularly, it was not clear how the differ-
CHAPTER 6. RESULTS OF THE CASE STUDY
66
ent backends, that we discussed in the architecture section, had to interact
together. This problem was also a consequence of the fact that the thirdparty APIs did not hide completely or at least sufficiently the interaction
between the backends. This hiding function should have been accomplished
by the CAN API mentioned in architecture section.
More specifically, the steps required to make the backends interact were
regarded as too many; additionally also the order of the steps was unclear.
Regarding these issues, some developers explicitly suggested a more advanced
visualization of the architecture for it to be understood. Though, another
developer added that if the SDK hid more, the deep understanding would
not have been required. This is a problem of the “abstraction level” the
third-party developer has to deal with.
To conclude, also this aspect highlighted a slightly too technical view
point in designing the platform resources that eventually hindered usability,
therefore it affected the overall developer experience.
6.2.2
Learnability
One of the main issues that affected developer experience regarded learnability. It emerged that the platform resources did not facilitate learning. A
major example is that the third-party APIs, because of their structure, did
not aid the learning process. As a general approach developers would have
preferred that the APIs were structured in such a way that is straight-forward
to perform basic operations. The more advanced options of those operations
could have been learned and used over time. Instead, it was easy to end up
using advanced options or operations, even deprecated ones, already at the
beginning.
Documentation is an important element of platform boundary resources;
specifically it belongs the social boundary resources (Ghazawneh, 2012). The
documentation has a very important role regarding learnability. It emerged
that that different developers have different approaches to learning: Some
need to go straight in to the source code and see working examples, while
others need to start from an overview and introductory concepts. Anyhow,
the documentation should have addressed those different learning patterns.
For example it was reported that the documentation for the Python APIs
was scarce; the developers had to look through the source code to gain understanding. The same approach had to be adopted for the REST API.
Anyhow, CAN Ecosystem’s standard documentation does provides code
snippets. Their limit is that they target specific use cases, or as a developer
described it: it is “code that always works”. A different approach to standard documentation was completed by a member of the support team during
CHAPTER 6. RESULTS OF THE CASE STUDY
67
hackathon. This was done in the form of a tool that could show directly the
result of some API calls. This kind of possibility was highly appreciated
by developers because they could play with the different calls and their attributes, thus gaining an immediate understanding. Unfortunately such a
tool was available only toward the end of the hackathon event.
Error messages are also an issue that affected learnability. Previously,
we reported that the SDK has essentially two levels. A lower level concerned
with the specific backends and a higher level (CAN API) that is meant to
bridge together the lower level APIs. It was reported that the higher level
(CAN API) was not catching the errors of the lower level APIs like the
storage-related one, but only its own; this made debugging quite difficult.
Some error messages were not very informative or difficult to understand.
For example the error messages regarding a notification channel from the
backend (Universal Event Broker) were affected by this problem.
6.2.3
Developer Portal and Registration Process
The developer had a general introduction to CAN Ecosystem in the initial
meeting we mentioned when describing the hackathon. In that meeting the
developers were given some instruction on how access the portal to download
the tools, and some information about the APIs structure and the authentication procedure.
However, the experience with the Developer Portal, particularly with the
process of registering as a developer, was regarded as unpleasant by some
developers. One of the developers explicitly reported that he assumed the
process to be complete once he gained access to the portal. Instead he was
given some application IDs whose function was not totally clear. He also
complained about the absence, in that circumstance, of a simple application
to test the usage of those IDs. That experience was described as frustrating.
The developer identified up to 4 steps necessary to have a complete developer
account, while in his opinion the developer should have sufficient information
to start using the APIs after only one step.
6.2.4
Support
As introduced when listing CAN Ecosystem’s social boundary resources, the
means of interaction between developers and the support team were based on
direct personal contact; ranging from face-to-face meetings to the the chat
group that was mainly used during the hackathon. During the hackathon, the
chat was been really important, and covered many functions. Primarily, in
case of any difficulties of using the APIs the developers could simply ask in the
CHAPTER 6. RESULTS OF THE CASE STUDY
68
chat and receive immediate response and help from a member of the support
team. Additionally it was used to notify developer of issues and or solutions
discovered by other participants. Through the chat, the support team also
gave, upon request, links to chunks of code in the common repository that
were used for testing and resulted successful; so that some developers could
understand better how to accomplish some specific tasks. Finally it also had
the function of bug reporting; meaning that if the support team did not find
a solution in a short time or a bug was discovered, these were added to a
backlog for future fixes.
6.2.5
Using the APIs
The usage of the APIs was reportedly easy, except for some specific issues.
The two main issues of the third-party API implementation can be described
collectively as a problem of ambiguity. To be more specific, one issue was
that there was some ambiguity in the use of the terminology (eg. the name
of some classes or methods) or which data type was expected as input for
some methods. A consistency issue was that there were too many possible
ways to reach the same outcome. For example it was discovered that there
were ten different calls for filtering or finding files. Whereas the developer
suggested that a cleaner implementation could be obtained by conceptually
structuring the APIs on two levels: basic operations and advanced usage
options. As reported before, this aspect also affects learnability. In the
beginning of the evaluation we claimed that the platform resources were
technically adequate. The developers acknowledged that it is straightforward
to access the content and “search” and “timeline” were regarded as the most
important and inherent functionalities of the system. With respect to these
basic functionalities the developers reported that it was “simple to get things
done” and it is just a matter of “presenting stuff in a good way”.
6.2.6
Authentication and Ticketing
It was already discussed, at the beginning of this Section, that device-based
authentication was a problem and it has been a major concern across the
teams. A developer also reported that this issue may constitute a problem
also for automated testing.
In addition to that, the authentication schema was not particularly appreciated. Specifically, there was an issue with the fact that the developers
had deal with exchanging tickets in order to make the three backends communicate. These tickets are a package that is given to an authenticated user,
and can be used as a proof of being the correct account holder. It was noted
CHAPTER 6. RESULTS OF THE CASE STUDY
69
that typically developers do not want to deal with these aspects, thus the
APIs should hide more. This offers a specific example of the “abstraction
level” problem presented in the Architecture Subsection. In the interviews,
both the terms tickets and tokens were used interchangeably; this comes
from the legacy of the different developers working on different parts of the
CAN Ecosystem stack. These terms interchanging is another example of the
ambiguity problem noted in the previous section.
6.2.7
Tagging issue
During the hackathon the main issue with the API that we noticed, was
with tagging; during an informal conversation with the participant that was
mainly consulted by the others regarding this issue. In this conversation
he explained that the API probably comes from a legacy system, and that
tagging works a bit like a file path. It was explicitly said that in a future
version of the API it should not be done that way.
6.2.8
Javascript
Javascripit (js) had been the “weapon of choice” for two of the teams. Inevitably, it was then mentioned quite a few times when reporting issues.
Some troubles were caused by some version-related issues with jQuery, an
external Javascript library. We regard this as an example reminding that,
especially in the context of software ecosystem, one needs to account for
external dependencies.
Other troubles were related to the authentication; but it is difficult to
distinguish if the problem was the authentication schema in general or how
it was implemented in the javascript API. However, we have to acknowledge
that it had been recently completed, and it also required a overnight fix
by the support team during the hackathon. In addition to that, during an
interview, one participant explicitly reported that once the authentication
issues were resolved, the Javascript API actually “made life easier”.
6.2.9
External Workers
Only one team decided to work with this part of the CAN Ecosystem. Being a really low level component it present a lot of concerns, at a general
level of security and reliability. Hence that team had to interact with the
equivalent of CAN Ecosystem but in a different environment. As explained
in the previous Section, CAN Ecosystem is a result of the storage component in a specific environment. This one team had to hack at such a low
CHAPTER 6. RESULTS OF THE CASE STUDY
70
level that it was considered safer for them not to use the standard version
of CAN Ecosystem, which is hosted in a production environment. The other
teams, instead, were working on a level where interacting with the production environment was safe. What emerged from the hackathon is that the
external worker module is simply not ready to be included in the platform
resources exposed to external developers. Specifically, security models have
to be defined and performance testing needs still to be carried out. In other
words this module needs to be developed further in order for it to be open to
third-parties; even if there was a mechanism for having selected third-parties
to work with it.
6.3
Summary
The findings from the hackathon experience, reported in the evaluation section, revealed the main issues concerning to which extent Content Anywhere
enables third-party development. However, regarding some other aspects
that went smoothly during the hacakthon may raise concerns, when considering, the CAN Ecosystem during normal operation. Meaning, when the
APIs are deployed in production environment and they are used by “real”
third-party developers. In the production environment the authentication
will be managed by the telecom operator that administers the platform or
whoever the platform owner is. It must be ensured that even though there
will be an addtional layer depending on another entity, the procedure of registering and getting started with the development is as smooth and quick as
possible. Another concern is that since there are different instances of CAN
Ecosystem that can be customized in different ways, the developers’ possibilities of reuse will be maximized. Meaning that there should be consistency
in the APIs so that third-party developers can participate and contribute in
the multiple instances of CAN Ecosystem. Alternatively the different platform owners of CAN Ecosystem instances should offer additional support
for the particular features of their platform. This would be similar to what
happens with Nokia’s Windows Phones. In Nokia’s developer portal they
offer additional support to the Windows phone SDK targeting the use of
those features that differentiate Nokia’s phone from the competitors inside
the windows phone market. This is clearly enabling those additional features and encouraging third-parties to develop applications only available on
Nokia’s Windows phones.
Another concern, that emerges when considering CAN Ecosystems’s boundary resources in a production setting, is about the scalability of the interaction between F-secure and the third-party developers. It is clear that the
CHAPTER 6. RESULTS OF THE CASE STUDY
71
processes in place during the hackathon are unscalable, and therefore unrealistic, in a real setting. For example, the developers participating in the
hackathon had a session where they were briefed on CAN Ecosystem and
they were given instructions on how to proceed with the authentication and
other practicalities for setting up the tool; additionally they could directly
contact, when needed, the developers of the APIs. It is still to be decided
how to achieve the same informative purposes in a scalable way.
The same applies to the support offered to developers at the various
stages of the development of the application. As it emerged before, it is
arguable how can this be scaled and how can the functions, covered by the
chat group, can be realized when there will be “real” external developers.
To our knowledge, there was, at the time of the hackathon, only an e-mail
address available to third-party developers and some basic forums.
The interaction with the third-party developers is extremely valuable.
As it emerged during the hackathon, developing application means exploring
the APIs at very low level of details and mashing them with other digital
services services. It is different from other testing practices, beacuse those
target specific use cases. This not only offers the possibility of finding bugs
and incompatibility issues, but also can offer insights about how to roadmap
the future development of the platform. During the hackathon, reporting
and suggestion functions were achieved through the chat group and direct
interactions. The question is, how obtain, in a scalable way, the same benefits
coming form close cooperation with the third-party developers.
Chapter 7
Discussion
In this chapter we discuss the main findings of our study in relation to the
research questions we presented in the introductory chapter. After answering
the research questions, we discuss our findings with related work, and finally
we make further observations.
7.1
Answering the First Research Question
The first research question we presented was:
How does F-secure enable third-party development through platform boundary resources?
This research question concerns the current status of CAN Ecosystem in
terms of the platform boundary resources exposed to third-party developers.
Summarizing the results of the case study, in relation to this first research question we can say that: The CAN Ecosystem is technically adequate;
meaning that, for third-party developers it is effectively possible to develop
software applications using the provided platform boundary resources, without major hiccups. For example, it is reportedly staight-forward to access
the main functionality CAN was created. CAN Ecosystem presents all the
elements that are generally recognized as platform boundary resources: A
resource for the first contact with the ecosystem, and whence to access the
other resources (i.e. the developer portal; an SDK composed of a number
of APIs supporting different programming languages, not including an IDE
since it depends on the programming language; Documentation, composed
of introductory material and a repository with code samples; basic means of
support and interaction with the keystone player.
72
CHAPTER 7. DISCUSSION
73
However, the CAN Ecosystem needs improvement regarding other aspects
that affect the overall experience. As a high level issue, it appears that the
design targets a too limited set of use cases, thus limiting some possibilities.
This is a problem because third-party developers typically create something
that the keystone player cannot fully predict. As pointed out earlier in this
thesis the case of platform boundary resources, particularly APIs, the design
process is more of an orchestration of components belonging to different
layers. Thus, the designers of the boundary resources cannot fully predict
how, or for which aim, they will be used. The challenge, for the designers, is
that boundary resources need to be weakly structured for general use, and
then become strongly structured for specific use; as for boundary objects in
general.
It appeared that the initial design did not address this issue successfully.
in this sense, the hackathon event, comprising application with diverse objectives and targeting different devices, helped emphasize the issue.
Finally, many aspects that impact learnability could be addressed better,
together with other issues like “abstraction level problem” or “ambiguity”
that do not facilitate third-party development.
In our view enablement is not a boolean value. Instead, as we realized
from our study, there are different degrees of facilitation, or minimization
of effort; and therefore different degrees of enablement. Nevertheless, we
deem that the minimum requirement, in order to talk about enablement of
third-party development, is ensuring technical feasibility.
We were not able to find, nor we were able to define, agreed and systematically defined degrees of enablement. For instance, we are not able to
define a maximum degree, or specific steps. However, from the knowledge
accumulated from the literature, we are able to recognize platform boundary
resources within the CAN Ecosystem; as reported in the beginning of this
section. We were also able to describe some of their features that raise the
degree of enablement; at least in the context of CAN Ecosystem.
In fact, from our findings, CAN Ecosystems has also elements that place
it above mere technical feasibility. As one example of these elements, we can
cite an online tool that allows seeing the result of single API calls and was
welcomed with satisfaction; unfortunately the tool was completed by the support team during the hackathon, and was not ready for the hackathon-based
testing. Some other elements like support and long term relationship could
not be realistically tested in the hackathon; and we raised some concerns in
that sense when we summarized the results of the case study.
As a final example of what can qualify as a platform boundary resource
and thus enable third-party development, we propose hackathons or similar
coding events. If organized in a similar way as our hackathon event, they can
CHAPTER 7. DISCUSSION
74
be a means that enables a closer cooperation between the keystone player
and third-party developers. In fact thinking in terms of boundary objects,
platform boundary resources are an artifact that minimizes the effort for
coordination within the collaboration of entities belonging to different social
words.
7.1.1
Comparison with Related Work
We based our concept of platform boundary resources on the work of Ghazawneh (Ghazawneh, 2012). It follows that what we regarded as platform
boundary resources in CAN Ecosystem is compliant with Ghazawneh’s definition and distinction between technical and social boundary resources. Ghazanaweh provides general level examples of platform boundary resources, while
we also provide examples of platform boundary resources that are specific to
the CAN Ecosystem. In fact, understanding platform boundary resources
as boundary objects gives more of a foundation to identify an artifact as a
platform boundary resource. An example of that is proposing a certain kind
of hackathon as a platform boundary resource.
APIs are definitely an important element of platform boundary resources
and certainly the most easy to identify as a boundary resource (Ghazawneh,
2012). We found a number of studies on APIs, but there is no point comparing them with our findings, as we did not provide any contribution in the
definition and description of APIs.
7.2
Answering the Second Research Question
The second research question we presented in introductory chapter was:
What does third-party developer experience consist of in Fsecure’s software ecosystem?
First of all, in relation to the first research question, it appeared that
third-party developer experience is concerned with the degree of enablement
perceived. We can say with a fair amount of certainty that third-party developer experience is affected negatively when the enablement is poor. One
example could be the drastic happiness level drops corresponding to major difficulties encountered. Many of these difficulties can be linked to the
platform boundary resources.
When we started discussing developer experience, we stated that the general definition of user experience can still hold for third-party developer experience. The definition mentions that the perceptions of the user are also
CHAPTER 7. DISCUSSION
75
affected by the “...anticipated use...”(ISO 9241-210). The anticipated use
can be intended as the expectations of the user; in this case the third-party
developer.
When talking about issues, the developers often expressed it in terms of
how something should be; in other words how they expected it to be, based
on their assumptions. For example the way in which tokens are handled, or
what is the level of abstraction exposed to third-party developers, or even
what kind of data structure is expected as input for a method.
We see this kind of unmet expectation as a product of the difference
between the mental model of the platform (and its parts) that the developer creates, and the mental model of the designers of platform boundary
resources. We think this is the highest level factor that composes thirdparty developer experience, for what we found in this context of the CAN
Ecosystem.
We also identified other factors that compose third-party developer experience. We have not exactly defined a hierarchy, however we believe that
learnability (which was introduced in the previous research question) is an
important factor. We used learnability to contain many issues, that could be
grouped in more specific categories.
Consistency, of how different part of the platform have to be used, is an
interesting factor, as we discovered it being related to expectations about
previously used parts of the CAN Ecosystem. This is because the CAN
Ecosystem is discovered and used progressively and in different iterations.
Consistency could be considered a factor composing learnability.
We propose that we could talk about usability factors when they are closer
to the level of detailed issues; like the presence of two functions to accomplish
a similar task, or an additional step. Whereas we can refer to experience
factors when they concern overall feelings. Usability factors contribute to
building these overall feelings and thus the experience.
7.2.1
Comparison with Related Work
Regarding what we refer to as third-party developer experience, the closest
related articles we were able to find are mostly concerned with API usability.
One study concerns the usability of APIs in Enterprise Service-Oriented
Architecture, and bases its criteria on learning barriers that are associated
with programming in general (Beaton et al., 2008). The barriers are classified
in terms of errors that caused them. Despite giving that are quite technologyspecific(i.e. SOAP), we can relate to some of their barriers with quite specific
findings: An example of what they call “naming Error” appears when we
discuss the usage of CAN APIs; Also what they refer to as “consistency
CHAPTER 7. DISCUSSION
76
Error” relates to our consistency problem we expressed in the same section;
though we still referred to it as ambiguity. The most relevant commonality,
though, is that the authors report violated expectations as a key issue. The
authors add that this leads the developer to question every assumption they
made about the API, and consequently to commit more errors.
In addition to this first article, there is a series of articles (Clarke, 2005,
2004; Stylos et al., 2008; Farooq and Zirkler, 2010) that are related to the
use of an adapted version of “cognitive dimensions” (Green and Petre, 1996).
These cognitive dimensions are a measure of what the third-party developer
can afford to do, and they are to be compared with the expectations the
developers have of the API. Within the set of 12 adapted cognitive dimensions
(Clarke, 2004) some relate to our findings: “Abstraction level” issues can be
found in the the problem of different backends and the ticketing problem we
reported in twice in the evaluation of CAN Ecosystem; addressing different
“learning styles” emerged when discussing learnability; “penetrability” is a
good description of the analysability criteria we selected from ISO/IEC 91261 ; “consistency”, that has already been discussed; “role expressiveness”
represents the concept of relating the different part of the API with each
other, as described in the section discussing the understendability of CAN
Ecosystem’s architecture; “domain correspondence” concerns how straightforward is to achieve a certain desired functionality, and is discussed within
the CAN APIs usage.
Finally, an article about Apple Computer’s HyperCard visual programming system (Nielsen et al., 1991) is entirely concerned with learnability
issues. In our evaluation we also grouped some issues under this category.
However the article of Nielsen et al. investigates in detail: learning time;
learning strategy; and learning curve.
To conclude, we can say that most of the articles cited in this Section
provide very detailed examples, down to the level of how some classes or
methods are defined. We based our evaluation on the judgment of F-secure’s
developers, and aimed at having a higher level of abstraction and provide
more general level examples and principles; with the goal of being independent from implementation details.
It is also important to remark that those articles are concerned specifically with API usability. Even though some of their findings can relate to
ours, APIs are not the only platform boundary resources. In our view, API
usability (or usability of other specific platform boundary resources) relates
to third-party developer experience, like the usability of buttons, scroll bars,
menus and other means of interaction relates to the whole user experience.
CHAPTER 7. DISCUSSION
7.3
77
Further Observations
In this section we want to highlight some aspects of our study on which
we have been speculating for some time. Yet, on these issues we have not
reached a final judgment. However we deemed important to introduce them
in order to engage a potential discussion.
7.3.1
Third-party Developer Segmentation
The subjects involved in our study were all F-Secure’s employees that volunteered for the hackathon event. We regarded the developer as a measure
of the third-party developers that will participate in CAN Ecosystem, and
we considered them as a homogenous group sharing common characteristics.
However other articles, that are concerned with issues related to our problem
domain, segment third-party developers into different profiles.
One study investigates an open source SECO (Kabbedijk and Jansen,
2011) and based on their activity of pushing to the repository, divides the
third-party developers into: “Lone wolf”; “Networker”; “One day fly”. This
segmentation seems useful to provide a descriptive account of the dynamics
of the ecosystem, however it does not bring insights into the different needs
and preferences of the developer groups.
The previously cited articles related to the cognitive dimension framework
(Clarke, 2005, 2004; Stylos et al., 2008; Farooq and Zirkler, 2010) also share
the use of developer personae or profiles. These profiles originate from different working styles and characteristics of developers using Microsoft Visual
Studio to develop software applications for Microsoft’s software ecosystem
(Clarke, 2005, 2004). The profiles are: Opportunistic, Pragmatic and Systematic. These profiles are not supposed to vary over time (i.e. no person
fitting a profile evolves into another after acquiring experience). Unfortunately Among all the articles we mentioned only one article (Clarke, 2004)
matches some usability goals for the APIs to a specific developer profile, but
they are at a general level and it does not provide more detailed examples.
So it is hard to see a relationship between how the segmentation shapes the
usability criteria.
Another article instead provides roles that change over time (Kline et al.,
2002). Meaning that in their study, Kline et al. divided the subjects of the
study into two groups: expert software developers and inexperienced ones.
It is interesting to note that the two groups exhibited areas of agreement
regarding some learnability and visibility of information issues (Kline et al.,
2002). So, in this case the segmentation did not provide different results
CHAPTER 7. DISCUSSION
78
in the experience; other than a higher general satisfaction level for expert
developers.
Regarding our findings, we can only add that it was suggested by a few
interviewees to offer two possible modes of operation of the APIs: An advanced mode for developers familiar with the platform and abasic mode for
inexperienced ones. This proposed segmentation potentially varies over time,
as opposed to what was suggested by Clark (Clarke, 2004). In fact thirdparty developers acquire more expertise as they continue developing using
certain platform boundary resources. Additionally, we reported that developers might have different learning styles. However, we do not have means
to determine whether those who shared a certain learning style share other
similar characteristics. Thus, justifying the segmentation study subjects into
categories
To conclude, since most of the articles do not provide clear examples,
it is hard to understand whether they achieved positive results in usability
and developer experience by segmenting developers. Besides that, one of the
studies (Kline et al., 2002) proved that some developer experience issues are
independent from the level of expertise of the developer.
7.3.2
Method
In our study, we used a hackathon event to collect empirical data. Borrowing
the terminology from ISO 9241-210, this can be considered a user-based
evaluation.
Also, the studies presented in the previous section have been applying
user-based evaluation. One study (Kline et al., 2002) has applied two methods: A heuristic evaluation, that appears to be an inspection-based evaluation; and a psychometric evaluation, that is a standard user-based evaluation.
Even though we described our method as user-based evaluation, because
F-Secure developer simulated the activity of third-party developers, in a sense
our study could also be considered an inspection-based evaluation. In fact,
our users qualify as experts since they have many years of experience in
software development and have been using different third-party APIs and
SDKs in their career. Moreover we have held semi-structured interviews, in
which F-secure’s developer were explicitly asked for their expert judgment
concerning broad issues. Whereas psychometric evaluations are based on
questionnaires that are analogous to structured interviews. Questionnaires
and structured interviews are more common in user-based evaluations.
Especially regarding heuristic evaluation, Kline et al. Kline et al. (2002)
presented the experienced developers with a table having predefined heuristics. It must be specified, that the study of Kline et al. is concerned with
CHAPTER 7. DISCUSSION
79
an IDE. We think it easier, in this case to use conventional user experience
for traditional computed-based (visual) interactive systems. On the other
hand, in our case we simply made some assumptions to define the points
that aided the semi-structured interviews; as we were not sure about what
third-party developer experience meant. Therefore we did not create any
specific heuristic in advance.
Because of this explorative nature of our study, despite having already
made some assumptions, we categorized the results as the issues emerged
from the data; instead of creating a predefined heuristic upfront. The way
we collected evidence around certain categories is explained in more detail
in the section related to data analysis.
Similarly, in the article of Beaton et al. (2008) the categories are created
after the study. However, in the other articles (Clarke, 2005, 2004; Stylos
et al., 2008; Farooq and Zirkler, 2010) a framework based on cognitive dimensions was already selected at the beginning, so that the issues found were
described in term of the cognitive dimensions. We are not sure if analysing in
terms of cognitive dimensions, the issues we observed from the CAN Ecosystem evaluation would have achieved better results; though we already stated
that those studies were only concerned with API usability.
Nonetheless, we think that the creation of a framework that proposes
criteria to assess third-party developer experience would be highly beneficial.
It could be used as a tool for the evaluation of software platforms, especially
before exposing the platform boundary resources to the public. Additionally
it would provide a common terminology to discuss third-party developer
experience issues.
Chapter 8
Validity Discussion
In this chapter we present some points for discussing validity issues related
to our study. We based our knowledge of the validity concept on the work
of Shadish et al. (Shadish et al., 1963).
The work of Shadish et al. is mostly concerned with experiments, and
particularly with dispensing treatments in controlled experiments. Despite
our careful planning the hackathon event does not qualify as an experiment
in a strict sense; for instance we did not have a control group.
The hackathon event has been an experiment only in the common meaning of the term; i.e. a first time experience associated with not exactly
predictable results. So it would be more appropriate to refer to it as the
setting. Yet, borrowing the word from chemistry, we could think of it as a
catalyst.
Nevertheless we believe we have elements to discuss our study in terms
of internal validity then construct validity and finally external validty.
8.1
Internal validity
Internal validity in concerned with the causal relationship between variables.
It is quite challenging for us to define exact variables; and even if we attempted, we would have more variables than data points.
Continuing the discussion concerning the first research question, a really
high-level variable would be the “degree of enablement”. As we explained
this high-level variable is composed of many factors. It is hard to define them
as variables because we were not able to observe variations in some variables
corresponding to variation of a treatment. Partially because we did not have
treatment, partially because we were not able to define exactly in which ways
the variables can vary.
80
CHAPTER 8. VALIDITY DISCUSSION
81
In this sense it is hard to stick with the concept of causal relationship
offered by Shadish et al. (Shadish et al., 1963). In any case, we can suggest
some issues that may have posed a threat to internal validity. For example,
since we relied on our subjects’ (F-secure developers’) judgment, they could
have not been conscious of some factors; they might have had different views;
or some subjects might have identified different factors than the one identified
by other subjects, however they might have been referring to the same factors.
Finally we have to admit that these last issues may be closer to problems
of construct validity.
8.2
Construct validity
In the end of the previous section we said that some of the concerns we
raised could belong to construct validity problems. In fact construct validity
is essentially concerned with definitions (Shadish et al., 1963).
Another issue that we deem relevant to argue about the subject of our
study. A key question is: To what extent do F-Secure’s developers that
volunteered for the hackathon event constitute a representation of the various
third-party developers that will interact with the CAN Ecosystem? This
leads to the question question: do developers of third-party applications have
relevant prototypical features that can be compared to F-Secure developers
or can they be aggregated into a broader group of individuals named software
developers? Additionally, is the construct identified at a too general or too
specific level? These questions are relevant when investigating the possibility
to generalize to population characteristics.
Considering the setting: The hackathon event was a convenient arrangement to collect data, is it a reasonable approximation of third-party software
development organization? Are there comparable dynamics?
All these examples we provided deal with the risk of inadequate explication of the construct; this can lead to construct confounding.
8.3
External validity
Concerns regarding external validity, in our opinion, depend on the kind
of contribution a study is aiming at. This study is very much focused on a
specific setting. However we may evaluate some possibilities of generalization.
As an example of same level generalization (Shadish et al., 1963): Given
that we could define some prototypical feature for the subjects of the study,
would inferences on what constitutes third-party developer experience still
CHAPTER 8. VALIDITY DISCUSSION
82
hold for a variation in the prototypical feature? A difference in the prototypical feature could be a different approach to learning; maybe due to the
level of education or cultural differences.
As an example of broad to narrow generalization we could question whether
a part of the platform boundary resources would be experienced in the same
way in a different setting? For instance, the support component considered in
another setting then the CAN Ecosystem, or another Software Ecosystem.
Chapter 9
Conclusions
Actively attracting third-party developers is a fundamental concern in a software ecosystem, especially in a keystone-centric one; given the fundamental
role that third-party developers have in the success of a software ecosystem.
In this direction, we deemed of particular interest to create additional
knowledge around the question of what makes third-party developers join
and develop software applications for a particular software ecosystem.
We already acknowledged that it is a complex problem, for there is a
complex interplay of different aspects. We decided to focus on the aspect
related to minimizing third-party developers effort. As this is understood to
be one of the important aspects.
We introduced the concept of platform boundary resources, and their
role in the enablement of third-party development. As we said, we understand minimizing third-party developers effort as enabling third-party development. We also highlighted that, ultimately, it is the third-party developer
who perceives the effort and benefits of enablement. Consequently we also
introduced the concept of third-party developer experience.
We decided to investigate these issues within a specific software ecosystem; namely the Content Anywhere Ecosystem. Additionally, we used the
expedient of a hackathon event to collect empirical data. The data was thereafter analysed to gain more knowledge from empirical evidence, and answer
our research questions.
In this sense, we investigated the phase when third-party developers start
familiarizing and making their first steps within the software ecosystem.
However some factors can impact also the long term relationship, because
of the iterative nature of how third-party developers learn and use the platform boundary resources.
As we learned, enablement can happen at different degrees; the bare
minimum is set at ensuring technical feasibility. There are a series of fac83
CHAPTER 9. CONCLUSIONS
84
tors related to platform boundary resources that help raise the degree of
enablement. And consequentially, we believe, this helps to raise the degree
of attractiveness of the software ecosystem, for the third-party developers.
At the same time, we learned that the third-party developer experience
is build on different levels. The lowest level concerns aspects that are closer
to the concept of usability. This lower level contributes to building overall
feelings, which in turn determine third-party developer experience. At any
level the experience is affected by met or unmet expectations. We understand
expectations as related to the mental model that the third-party developer
creates.
As we said, the third-party development experience is concerned with
the degree of enablement perceived. So this helps in understanding, at least
partially, what are the elements of attractiveness in a software ecosystem for
third-party developers.
9.1
Future Work
We think that there are many possible directions that could be taken to
explore further the issues we presented in this master’s thesis. One approach
could be to extend the area of our study; for example changing the scope of
our study, or concentrating on another phase of the interaction between the
third-party developer and software ecosystem.
Regarding the first example, an area for future studies could be analysing
the economic reasoning of third-party developers, or better, of third-party
development organizations; this could be called business experience. Similarly one could investigate how keystone players harness open innovation,
and discuss it in terms of intellectual-propriety-rights experience.
As for the second example, the study can be extended to the growth
of Content Anywhere Ecosystem. Maybe it could be a longitudinal study
composed of multiple case studies depicting various stages of the SECO’s
growth. In this case, it could be interesting to observe how the relationship
between the keystone player and the third-party developer evolves. So the
focus could be on sustaining the relationship and collaboration. A different
approach, would be to do a longitudinal study comprising studies that analyse
issues in other software ecosystems and compare the results; that would
potentially give more grounds for generalization.
On the other hand, some issues that we discussed in this master’s thesis
could be explored in depth. In this sense, we can list some proposals.
For example, learnability aspects could be investigated further. In this
sense, platform boundary resources could be analysed in terms of learning
CHAPTER 9. CONCLUSIONS
85
time, learning strategy and learning curve. This could also provide the possibility of introducing quantitative measurements.
Another direction, could be to analyse in depth the relation between the
different elements that compose third-party developer experience. Or, within
the same topic, how the third-party developers build their mental model
of the different parts of the software platform and how platform boundary
resources work; consequently, also how to help them in building the mental
model.
Additionally, a study could focus on defining more systematically the
degrees of enablement, and explicitly identify elements that make a SECO
qualify to possess a certain degree of enablement.
Finally, continuing with the parallel between third-party developer experience and user experience, it could be studied whether there are elements
of pleasurability in third-party developer experience, as there are in user
experience. Or whether pleasurability is one of the criteria to achieve the
maximum degree of enablement.
Bibliography
AaltoES. Aaltoes build it - 3d printing with add lab, 2013. URL http://www.
aalto.fi/en/current/events/built_it_3d_printing/. Accessed 2013-0402.
C. Baldwin and J. Woodard. The architecture of platforms: A unified view.
Harvard Business School Finance Working Paper, (09-034), 2008.
J. Beaton, S. Y. Jeong, Y. Xie, J. Stylos, and B. A. Myers. Usability
challenges for enterprise service-oriented architecture apis. In Visual Languages and Human-Centric Computing. IEEE Symposium on, pages 193–
196. IEEE, 2008.
M. Bergman and G. Mark. Boundary objects in design: an ecological view
of design artifacts. Journal of the AIS, 8(1):34, 2007.
J. Bosch. From software product lines to software ecosystems. In Proceedings
of the 13th International Software Product Line Conference, pages 111–
119. Carnegie Mellon University, 2009.
J. Bosch. Software ecosystems: Taking software development beyond the
boundaries of the organization. Journal of Systems and Software, 85(7):
1453–1454, 2012.
J. Bosch and P. Bosch-Sijtsema. From integration to composition: On the impact of software product lines, global development and ecosystems. Journal
of Systems and Software, 83(1):67 – 76, 2010a.
J. Bosch and P. Bosch-Sijtsema. Softwares product lines, global development
and ecosystems: Collaboration in software engineering. In Collaborative
Software Engineering, pages 77–92. Springer Berlin Heidelberg, 2010b.
K. Burnham. Inside facebook’s hackathons: 5 tips for hosting your
own, 2012. URL http://www.pcadvisor.co.uk/news/internet/3377232/
86
BIBLIOGRAPHY
87
inside-facebooks-hackathons-5-tips-for-hosting-your-own. Accessed
2013-02-06.
C. C. Centre.
Cern summer student webfest, 2012. URL http://www.
citizencyberscience.net/cern-webfest/. Accessed 2012-10-25.
S. Clarke. Measuring api usability. Doctor Dobbs Journal, 29(5):S1–S5, 2004.
S. Clarke. Describing and measuring api usability with the cognitive dimensions. In Cognitive Dimensions of Notations 10th Anniversary Workshop: In Conjunction with the IEEE Symposium on Visual Languages and
Human-Centric Computing. IEEE, 2005.
K. Crowston, J. Howison, C. Masango, and U. Eseryel. The role of face-toface meetings in technology-supported self-organizing distributed teams.
Professional Communication, IEEE Transactions on, 50(3):185–203, 2007.
M. A. Cusumano and A. Gawer. The elements of platform leadership. MIT
Sloan Management Review, 43(3):51 – 58, 2002.
C. R. De Souza, D. Redmiles, L.-T. Cheng, D. Millen, and J. Patterson. How
a good software practice thwarts collaboration: the multiple roles of apis
in software development. In ACM SIGSOFT Software Engineering Notes,
pages 221–230. ACM, 2004.
T. Eisenmann, G. Parker, and M. W. V. Alstyne. Strategies for two-sided
markets. Harvard Business Review, 84(10):92 – 101, 2006.
U. Farooq and D. Zirkler. Api peer reviews: a method for evaluating usability
of application programming interfaces. In Proceedings of the 2010 ACM
conference on Computer supported cooperative work, pages 207–210. ACM,
2010.
A. Gawer and M. A. Cusumano. How companies become platform leaders.
MIT Sloan management review, 49(2):28–35, 2008.
A. Ghazawneh. Towards a Boundary Resources Theory of Software Platforms. PhD thesis, Jönköping University, JIBS, Business Informatics, 2012.
A. Ghazawneh and O. Henfridsson. Governing third-party development
through platform boundary resources. In ICIS 2010 Proceedings, pages
1–18. AIS Electronic Library (AISeL), 2010.
BIBLIOGRAPHY
88
A. Ghazawneh and O. Henfridsson. Micro-strategizing in platform ecosystems : A multiple case study. In Proceedings of the International Conference on Information Systems, ICIS 2011, Shanghai, China, December 4-7,
2011. Association for Information Systems 2011, pages 1–19. AIS, 2011.
A. Ghazawneh and O. Henfridsson. Balancing platform control and external
contribution in third-party development: the boundary resources model.
Information Systems Journal, 23(2):173–192, 2012.
T. R. G. Green and M. Petre. Usability analysis of visual programming
environments: a ‘cognitive dimensions’ framework. Journal of Visual Languages & Computing, 7(2):131–174, 1996.
G. K. Hanssen. A longitudinal case study of an emerging software ecosystem:
Implications for practice and theory. Journal of Systems and Software, 85
(7):1455–1466, 2012.
G. K. Hanssen and T. Dybå. Theoretical foundations of software ecosystems. In Proceedings of IWSECO, page 6. INFORMSCEUR Workshop
Proceedings, 2012.
P. Huang, M. Ceccagnoli, C. Forman, and D. Wu. When do isvs join a
platform ecosystem? evidence from the enterprise software industry. In
Proceedings of the 30th International Conference on Information Systems,
pages 15–18. AIS, 2009.
S. Jansen, S. Brinkkemper, and A. Finkelstein. Business network management as a survival strategy: A tale of two software ecosystems. In First
Workshop on Software Ecosystems, pages 34–48. CEUR-WS, 2009a.
S. Jansen, A. Finkelstein, and S. Brinkkemper. A sense of community: A research agenda for software ecosystems. In Software Engineering - Companion Volume, 2009. ICSE-Companion 2009. 31st International Conference
on, pages 187–190. IEEE, 2009b.
S. Jansen, S. Brinkkemper, J. Souer, and L. Luinenburg. Shades of gray:
Opening up a software producing organization with the open software enterprise model. Journal of Systems and Software, 85(7):1495 – 1510, 2012.
J. Kabbedijk and S. Jansen. Steering insight: An exploration of the ruby
software ecosystem. In Software Business, pages 44–55. Springer, 2011.
A. M. Kaplan and M. Haenlein. Users of the world, unite! the challenges
and opportunities of social media. Business horizons, 53(1):59–68, 2010.
BIBLIOGRAPHY
89
T. Kilamo, I. Hammouda, T. Mikkonen, and T. Aaltonen. From proprietary
to open source–growing an open source ecosystem. Journal of Systems and
Software, 85(7):1467 – 1478, 2012.
R. Kline, A. Seffah, H. Javahery, M. Donayee, and J. Rilling. Quantifying
developer experiences via heuristic and psychometric evaluation. In Human Centric Computing Languages and Environments, 2002. Proceedings.
IEEE 2002 Symposia on, pages 34–36. IEEE, 2002.
H. Lapp, S. Bala, J. P. Balhoff, A. Bouck, N. Goto, M. Holder, R. Holland,
A. Holloway, T. Katayama, P. O. Lewis, et al. The 2006 nescent phyloinformatics hackathon: a field report. Evolutionary Bioinformatics Online,
3:287, 2007.
S. Leckart. The hackathon is on: Pitching and programming the next killer
app. Wired, 2012. URL http://www.wired.com/magazine/2012/02/ff_
hackathons/all/.
K. Manikas and K. M. Hansen. Software ecosystems-a systematic literature
review. Journal of Systems and Software, 86(5):1294–1306, 2013.
D. G. Messerschmitt and C. Szyperski. Software ecosystem: understanding
an indispensable technology and industry. The MIT press, 1st edition, 2003.
ISBN 0262134322.
M. D. Myers. Qualitative research in business & management. SAGE Publications Limited, 1st edition, 2008. ISBN 9781412921657.
J. Nielsen, I. Frehr, and H. O. NYMAND. The learnability of hypercard as
an object-oriented programming system. Behaviour & Information Technology, 10(2):111–120, 1991.
M. B. Osvald and C. W. Robert. An inside view of ibm’s ’innovation jam’.
MIT Sloan Management Review, 50(1):32–40, 2008.
M. Raatikainen, M. Komssi, V. Dal Bianco, K. Kindström, and J. Järvinen.
Industrial experiences of organizing a hackathon to assess a device-centric
cloud ecosystem. In Proceedings of the 37th Annual International Computer Software & Applications Conference, 2013.
W. Scacchi and T. A. Alspaugh. Understanding the role of licenses and
evolution in open architecture software ecosystems. J. Syst. Softw., 85(7):
1479–1494, 2012.
BIBLIOGRAPHY
90
W. R. Shadish, T. D. .Cook, and D. T. Campbell. Experimental and Quasiexperimental Designs for Generalized Causal Inference. Houghton Mifflin
Company, 1st edition, 1963. ISBN 0395307872.
J. Stylos, B. Graf, D. K. Busse, C. Ziegler, R. Ehret, and J. Karstens. A
case study of api redesign for improved usability. In Visual Languages and
Human-Centric Computing, 2008. VL/HCC 2008. IEEE Symposium on,
pages 189–192. IEEE, 2008.
E. von Hippel and R. Katz. Shifting innovation to users via toolkits. Management Science, 48(7):pp. 821–833, 2002.
R. K. Yin. Case study research: Design and methods. SAGE Publications,
Incorporated, 3rd edition, 2002. ISBN 0761925538.
Y. Yoo, O. Henfridsson, and K. Lyytinen. Research commentary—the new
organizing logic of digital innovation: An agenda for information systems
research. Information Systems Research, 21(4):724–735, 2010.
J. L. Zittrain. The generative internet. Harvard Law Review, 119(7):1974–
2040, 2006.