Platform ecosystem participants often draw from capabilities provided to them by other actors in the ecosystem. While heralded as a driver of innovation, it is unclear how exactly platform evolution is affected by this dynamic. In this short paper we apply event sequence analysis to extract and analyse sequential patterns related to capability redeem - i.e. the internalization and subsequent utilization of external capabilities - on platform ecosystems. We find that development sequences differ in their order of events depending on whether a new capability is being integrated as opposed to the capability being put to use to create novel functionality. In particular, we find evidence for two sequence patterns. First, the platform adapting to new resources and incorporating fresh capabilities, leading to little changes in the functionality of the platform. Second, newly gained capabilities are put to use to enhance platform functionality, incurring substantial adjustments to its external behaviour. Located in information systems research on platform-ecosystems these initial findings present potential for future studies.
Ecosystem dynamics are key in understanding the innovative potential
of digital platforms. Complex interdependencies fuel the continuous,
iterative, and generative manner in which information resources are
recombined across organizational boundaries in order to create digital
innovations [
While the literature has explored mechanisms of sharing capabilities across platform-based ecosystems, it is unclear how exactly the incorporation and subsequent utilization of ecosystem capabilities plays out and how changes to platform development can be understood. Understanding these developments in platform-ecosystems contexts is important as it would advance the basis for insights on distributed digital innovations.
In this short paper, we therefore demonstrate an approach to study the detailed changes that arise when platforms align their resource base and incorporate capabilities provided through others in their ecosystem. We address the research question; What are sequences of events of capability redeem in platform-ecosystems? Drawing on the notion of capability redeem, we are particularly interested in the chain of events during the integration of capabilities to be gained as well as their subsequent utilisation.
We present the case of the OpenStreetMap.org (OSM) platform to answer the above research questions and report initial evidence from a larger study on platform development. Conceptualising capability redeem as a two stage process that involves integrating as well as using the newly gained capability, we identified two focus episodes from the case. By applying computational event sequence analysis to each episode, we explicate trajectories of changes to understand how redeeming ecosystem capabilities influences the development of new functionality on the OSM platform.
The remainder of the paper is structured as follows. In the next section we frame our approach to capability redeem through ecosystem participation by briefly reviewing relevant literature. We then detail our approach by highlighting the empirical context as well as event sequence analysis methods. Finally, we present initial results before concluding and pointing to opportunities for further research.
Co-evolving organisational capabilities through ecosystem
participation is a notion firmly rooted in the information systems
literature [
Considerable work has gone into explicating the mechanisms by
which the exchange of resources and capabilities foster innovation for
participants. For instance, some point out that providing interfaces
facilitates innovation and growth in platform ecosystems [
Resolving such tensions is the purpose of governance, which aims to
align detrimental interest between participants. To meet competing
demands, authors have suggested different governance principles [
Relevant IS literature advocates benefits of ecosystem participation.
Participants have a clear interest in drawing from capabilities offered
through the ecosystem as far as this advances their ability to innovate [
For this paper, we draw on the idea of capability redeem [
We examine the case of the openstreetmap.org (OSM) platform to
study how capability redeem in a platform ecosystem is unfolding. OSM,
the platform, is an open source software artefact which produces the
assets of OpenStreetMap, the geo-spatial data project, available both via
programmable interfaces and via the browser. In operation since 2004,
‘the Wikipedia of maps’ [
OSM is a well-suited case to showcase our empirical approach and discuss capability redeem in an ecosystem context. Over time, the platform has been adapted and extended to draw on many technical solutions provided by other (mostly open source software) projects such as leaflet.js (a library for interactive maps), Rails (a web development framework), and Mapnik (a rendering engine). In turn, OSM provides actors in the OSM ecosystem various capabilities to handle geo-spatial data. These capabilities are immensely popular and several hundred commercial and non-commercial web services are drawing from OSM data and related data handling capabilities in their configurations, for instance, Craigslist, Wikipedia, and Foursquare2.
The position of OSM as simultaneously a focal actor to its own
ecosystem and non-focal actor in relation to other ecosystems (such as
the ecosystem around leaflet.js, Rails, and Mapnik) presents a fit with
the conceptual perspective on ecosystems proposed by [
To focus the study, we identified a pertinent episode of capability redeem in the context of OSM that demonstrably resulted in innovation. Our conceptualisation of capability redeem implies two related yet distinct streams of activity. First, the addition of the desired capability to the suite of platform resources. Second, the utilisation of the gained capability for innovation on the platform. 1 Database statistics as of October 2016, available at: http://www.openstreetmap.org/stats/data_stats.html 2 http://wiki.openstreetmap.org/wiki/List_of_OSM-based_services
As such we chose the update of Ruby on Rails to version 3.0 and
subsequently version 3.1 as our first episode of interest. As a subsequent
episode of utilisation of newly gained capabilities related to the Rails
update, we chose the extension of the OSM data model with redactions,
i.e. the possibility to prevent the circulation of OSM data objects across
all instances of the OpenStreetMap database. The Rails update episode
and the resulting utilisation of the capabilities gained from it are a
meaningful representation of capability redeem on OSM. The Rails
update 3.0/3.1 focused substantially on the interaction between Rails
components and database operations. Through the set of novel
capabilities OSM was able to react swiftly to two external events that
made adjustments to the platform necessary. First, the inclusion of
redactions as an extension to the OSM data model, protected OSM from
copyright infringement allegations, should data be distributed that
violated intellectual property rights of others. Second, in 2010 the project
underwent a license change from CC-BY-SA3 towards ODbL4 covering
the OpenStreetMap data. This made it necessary to exclude all data
points committed to OSM from distribution for which the new license
agreements have not been accepted by the uploader yet. We
conceptualise these examples as illustrations of our approach while
framing the paper with the conceptual lens that capability redeem
provides. As stated earlier, OSM is dependent on the Rails ecosystem to
provide capabilities needed in operating OSM in its current form [
We queried the GitHub web API and downloaded all source code
changes committed to the OSM Rails port. Specifically, we focused on
changes made to the ‘rails controllers’. In the Rails architecture,
controllers manage any information processing activity in web
applications (called business logic in other contexts). Controllers
3 Creative Commons Attribution Share Alike
4 Open Data Commons Open Database License (similar to CC-BY-SA, but specifically for data)
coordinate operations between the data model and the various views
presented to the user [
With the constrains described above we used the downloaded commits
to construct an event sequence dataset [
Some data transformation was necessary to allow a meaningful analysis of the collected sequential data. First and foremost, manual filtering was necessary to eliminate noise that was introduced to the data by the temporal order of commits. All commits have been ordered by continuous calendar time based on the timestamps provided by GitHub metadata5. This consequently implied a relation 5 Note: We use the timestamps the commit was added to the code base (as opposed to when the commit was authored) between events (i.e. commits) by virtue of having occurred immediately before or after one another. This was the case regardless whether these events are causally related, that is, actually relating to the same source code issue. Against the backdrop of the identified episode of capability redeem this required to identify and derive a subset from the data that contained commits exclusively referring to the two episodes ‘Rails Update’ and ‘Redaction Implementation’ respectively.
Filtering of events was informed by the Rails change logs6,7 to
identify potential source code changes relating to aspects of the Rails
update. Prolific changes that guided the data cleaning are detailed in
Table 2. Consequently, the number of all commits associated with
every component was reduced to commits that were clearly
attributable to the ‘Rails Update’ (n = 144) and the ‘Redaction
Implementation’ (m = 37) respectively.
(3) Records of Activity: The second part of bi-modal data for sequence
analysis requires a finite set of mutually-exclusive categories of
activity [
Events of type ‘documentation’ were not found in the two focus episodes
Events of types ‘preventive’ and ‘performance’ were omitted from the analysis as they are
effectively unrecognisable without more intimate knowledge of the change process; Also see
[
Classification was conducted by examining each commit through the associated URL provided by GitHub, assessing the source code changes made to every file and deciding on a classification of the changes. The approach assured that commits changing multiple components are classified according to the source code changes they made to each respective component. Ties in classifications were resolved through discussions with agreement averaging 73.94% after three iterations of coding. (4) Timeline of Observation: The rails update 3.0 was initiated on November 14th 2011. The inclusion of redactions to the data model began on April 5th 2012. By December 10th 2013, the Rails Port was once again updated to Rails 4.16, marking the end point of this study’s observational timeline. To showcase our approach, we hence only consider events that have taken place in the 25 months between November 2011 and December 2013. This delimitation allows the construction of a clear timeline with well-defined start and end points.
In sum, the outlined approach resulted in the creation of an event sequence data set, comprising 27 sequences (19 relating to Rails Update, 8 to Redact Implementation) each representing all relevant change made to one of the affected components in the time from November 2011 to December 2013. Figure 1 below presents an illustrative event sequence with the coded short label for each event type. Introduction of new APIs for web applications; e.g. Mailer API for mail notification capabilities provided by Rails Complementing Active Record methods in database queries by explicitly supporting AREL function calls in database handling Update of xml_to_html requests leads to changes in javascript pushstate functions used to interact with client application (e.g. browser history) Adjustments to CSRF token check now activated by default and evoked in “app/controllers/application_controller.rb”
New default javascript framework for AJAX queries in Ruby 3.2 Data Analysis
We use computational event sequence analysis to the filtered, ordered
and coded datasets to study the chain of events occurring in the identified
episodes that we conceptualise as part of capability redeem. We are
specifically interested in the piecemeal steps constituting patterns within
and across sequences. We therefore organised the dataset in an event
sequence structure and aligned sequences by event order. This allows the
time agnostic analysis of individual events and prioritises the
investigation of event order, shared sub-sequences and common event
transitions over duration and timing of events [
Two questions guide the analysis of the development sequences; First, do sub-sequence patterns differ across episodes? Second, what wholesequence patterns are characteristic for each respective episode?
First, we extracted discriminant sub-sequences following an approach
described in [
The second stage of the analysis is concerned with the derivation of
representative whole sequence patterns in each episode. To that end, we
apply optimal matching analysis to the whole sequences. Albeit nascent
in social science research, optimal matching is an established approach
to dealing with sequential data with prominent applications in sociology
and origins in biology [
TraMineR uses the established ‘Needleman–Wunsch’ algorithm to
compute a similarity measure for each pair of sequences [
The cost regime is not arbitrary as sequence alignment operations and
their costs are best informed by subject matter expertise and research
context [
Applying Needleman-Wunsch with the Levenshtein cost regime yields
a dissimilarity matrix with the minimal similarity scores for each
sequence. Following an approach described by [
The results indicate that the sequence of events in each episode differ substantially. Both, the analysis of sub-sequence elements as well as representative whole-sequences provide evidence for the existence of fundamental differences in the sequential patterns of source code changes in both selected episodes. We report these initial findings according to the two guiding questions on sub-sequence and wholesequence differences.
First, we were interested in potential differences in the order of events in each development episode asking the question: Do sub-sequence patterns differ across episodes?
The result from the discriminant sub-sequence analysis clearly indicate that the two episodes differ in terms of the elements and subsequences that constitute the chain of events in each episode. Figure 2 below displays the 25 most determinative sub-sequences for each episode. For reasons of visual accessibility, we only plot sequences with maximum length of three elements. Given the low average length of sequences in our sample, this does not present a limitation.
In general, the events associated with the ‘Rails Update’ episode predominantly display sub-sequences that begin with an ‘adaptive’ event (17 of 25), followed by various combinations of the events ‘corrective’, ‘groomative’, or ‘reductive’. The frequency of events of the ‘enhancive’ category (i.e. adding new functionality) are rare in that group (indicated by the downward direction of the bar representing the sign of the Pearson residual). Interestingly, no sub-sequence is statistically significant for this episode (statistical significance refers to chi square test results between episodes). This indicates that sequence patterns exist in too great a variety within the episode to be conclusive about what subsequences are determinative.
In contrast, consider the sub-sequence patterns that characterise the
‘Redaction Implementation’ episode. Here, sub-sequences beginning
with ‘enhancive’ events are not only more frequent (6 of 25), but are also
statistically significant in terms of their chi-square test results (indicated
by the grey shading of bars) [
Sub-sequence elements with ‘adaptive’ events in the beginning or among the first sequence elements are common across the ‘Rails Update’ episode. In contrast they are less so in the ‘Redaction Implementation’ episode. In fact, two of the sub-sequence spells beginning with an ‘adaptive’ event are negative identifiers. That is, on a .05 significance level, a sub-sequence can be categorised as not being from the ‘Redaction Implementation’ episode if it contains these patterns. 4.2 Representative Whole-Sequence Patterns
Next, we turn to the analysis results of whole-sequences, asking; What
whole-sequence patterns are representative for each episode? We
therefore used the dissimilarity matrix as described above to derive
sequences of source code changes that are representative of each episode.
We extracted the five sequences from each episode with minimal
dissimilarity scores. These sequences are referred to as representative
sequences as they display cases for which the effort needed to transform
them in any other sequence is lowest [
Consistent with the analysis of sub-sequence elements, the analysis of whole sequences confirms the differences of sequence within each episode. The five most representative sequences in the ‘Rails Update’ episode all start with ‘adaptive’ events, followed by either ‘reductive’ or ‘corrective’ code changes. Only exception to this are two sequences (#4, #5) exhibiting an event of type ‘enhancive’ later in the sequence.
The pattern can be interpreted as incorporating external capabilities to the OSM platform artefact. The source code changes needed to ‘adapt’ to the new capabilities gained from updating Rails initiate the sequences, while the rest of the development work is characterised by correcting functions by either fixing or restricting them (‘corrective’ or ‘reductive’ events) or as in one occasion maintaining the appearance or style of the code base. The top 5 sequences are illustrated in Figure 3 below. Fig. 3. Top 5 representative development sequences for the Rails 3.0/3.1 Updates per component; Labels correspond to the coded event types of source code changes; A = Adaptive, C = Corrective; E = Enhancive; G = Groomative; R = Reductive
The sequences in the ‘Redaction Implementation’ episode stand in stark contrast to the ones in the ‘Rails Update’. Here, without exception, the most representative sequences all begin with an ‘enhancive’ event indicating the addition of new functionality to respective components. The sequences proceed with high variety of possible events before ending with variations of ‘groomative’, ‘corrective’ or ‘adaptive’ events. As in the analysis of sub-sequence patterns, the event of type ‘reductive’ is absent from this set of sequences. (see Figure 4)
The pattern can be interpreted as utilizing the newly gained capabilities by adding new functionality to the artefact. Related to the introduction of novelty (‘enhancive’ events) is the adjustment of resources indicated by ‘adaptive’ events. The majority of succeeding events deals with the aligning existing functionality indicated by ‘corrective’ events as well as maintaining standards in the source code base as represented by ’groomative’ events. Given the small number of eight sequences in this episode, the pattern across the five representative sequences is especially remarkable.
Fig. 4. Top 5 representative development sequences for the implementation of redaction resources; Labels correspond to the coded event types of source code changes; A = Adaptive, C = Corrective; E = Enhancive; G = Groomative; R = Reductive
In summary, the apparent differences in sub-sequence and wholesequence patterns indicate contrasts in the unfolding event order during capability redeem affecting platform evolution. The sequences of source code changes in the ‘Rails Update’ episode consists of events associated with maintaining of functionality by use of newly available resources (‘adaptive’ events). This adaptation is followed by dealing with edge cases, corrections, and restrictions of existing functionalities later in the development sequence (‘corrective’ and ‘reductive’ events). The addition of novel functionality is rare in the entire episode as refelcted by only two elements of type ‘enhancive’ in the representative sequences in figure 3. This is unsurprising, given that the alignment of the resource base through interaction with an ecosystem such as Rails entails adjusting the resources needed to perform functionality. From the perspective of capability redeem, OSM is a non-focal actor which needs to accommodate changes in the Rails ecosystem to keep profiting from redeeming capabilities from Rails.
Conversely, the ‘Redaction Implementation’ episode is characterised by numerous additions of new functionality, followed by aligning resources as well as tending to maintainability of source code. This is evident from the prevalence of ‘enhancive’ events in the beginning of the representative sequences followed by combinations of ‘corrective’, ‘groomative’, and ‘adaptive’ events (compate figure 4).
Evidence from the ‘Rails Update’ episode of integrating capabilities gained from an ecosystem partner does not support conclusive statements at this point. None of the sub-sequence patterns are significantly different from the sequences contained in the second episode. While revealing interesting descriptions of the source code changes entailed in the integration of redeemed capabilities, this highlights a need for further investigation. Contrarily, the episode dealing with the utilisation of newly gained capabilities from ecosystem partners by implementing a new feature, offers promising avenues for further research. Implicit in the sequence of source code changes associated with the second episode is the notion that the inclusion of novel functionalities alters the external behaviour of the software. While not surprising in itself, this idea invites reflections about how the evolution of platform-ecosystems is affected by redeeming capability from ecosystem actors. The OSM platform clearly benefits from integrating capabilities and resources provided by the Rails ecosystem. While not advancing functionality of OSM software immediately during the implementation, our evidence suggests that subsequent design of novel functionality is substantially affected by the capabilities OSM developers gained by aligning with updated Rails resources.
Several avenues for further research on platform-ecosystems are
possible based on initial insights showcased here. First, a perspective on
digital innovation through path constitution theory ([
Furthermore, questions concerning changing design rules [
Lastly, our approach highlights the feasibility of tracking platform development on the level of individual components. As such, development sequences can be related to questions of platform component composition (see [38]). For instance, the time needed for a component to fully adopt a new functionality change or the rate with which changes occur in a component present opportunities for investigations on platform development as a function of the ease with which its components incorporate changes. Using measures relating to sequential dynamics would thus allow to derive insights on platform evolution.
On a final note, we hope that despite its early stage character, this paper demonstrates computational sequence analysis as a potentially fruitful approach for anyone interested in understanding digital technology development in platform-ecosystem contexts.
The authors would like to thank two anonymous reviewers as well as the participants of the Pre-ICIS event ‘8th International Workshop on Software Ecosystems’ on December 10th in Dublin, Ireland for their helpful comments on an earlier version of this paper. Modularity. Cambridge, MA: MIT Press. Cambridge, MA: MIT Press, 2000. [38] A. Tiwana, Platform Ecosystems: Aligning Architecture, Governance, and Strategy. Amsterdam: Morgan Kaufmann, 2014.