Open data platforms: Design principles for embracing outlaw innovators

Open data platforms freely provide citizens with access to public data, thus enabling improved governance transparency, enhanced public services, and increased civic engagement. However, unlocking the potential of this digital transformation strategy requires that public institutions manage the tension between public and private interests. Furthermore, even when public institutions break down traditional barriers for citizens ’ access to data, the potential users often lack the knowledge to leverage it in meaningful ways. Open data platforms therefore tend to fall short of expectations. Leveraging a 10-year action design research study (ADR) in the Swedish Transport Administration (STA), this paper develops design principles for creating value-generating open data platforms in the public domain. The ADR project was initiated to assist STA in its efforts to deal with outlaw innovators who scraped train data from different websites to develop travel apps. Through three iterative design cycles that eventually led to the formation of a new open data platform, the outlaw innovators increasingly became valued partners in the digital transformation process. Theorizing this development process, this paper offers three design principles that provide guidance to public institutions aspiring to digitally transform by making public data accessible. We also reflect upon how these institutions might mitigate the risks associated with partnering with outlaw innovators in the pursuit of an open data strategy.


Introduction
Open data is government-related and machine-readable data made freely available to the public to accomplish transparency, civic engagement, social benefits, and public service innovation (Janssen, Charalabidis, & Zuiderwijk, 2012;Zuiderwijk, Janssen, & Davis, 2014).Such digital transformation in the public sector enhances the relationship between institutions and citizens (Wainwright, Huber, Stöckmann, & Kraus, 2023).For example, when public institutions provide access to datasets that are relevant to specific use cases − rather than compiling applications for such use cases − external developers are likely to develop innovative services that meet diverse citizens' needs (Magalhaes & Roseira, 2017).Open data is therefore a key driver for a paradigm shift in the business of government (Cingolani, 2021).
While pursuing an open data strategy might appear to be relatively straightforward, open data platforms have tended to fall short of generating benefits for citizens (Attard, Orlandi, Scerri, & Auer, 2015;Chen, Cao, & Liang, 2023;Gascó-Hernández, Martin, Reggi, Pyo, & Luna-Reyes, 2018).This is often caused by poor data quality (i.e., inaccurate, incomplete, outdated information) (Sadiq & Indulska, 2017), and misalignment between the data a public institution is willing to publish and the data required for meaningful citizen services (Hein et al., 2023).In addition, the average citizen that is envisaged as the user of these platforms usually lacks the skills − or faces insurmountable technical barriers − to derive value from the data (Zhu & Freeman, 2019).Both institutions and citizens need requisite competencies for an open data platform strategy to succeed (Bonina & Eaton, 2020).
The objective of this paper is to contribute to the literature on digital transformation of the public sector by theorizing the evolution of a successful open data platform.Key to achieving this success was the public institution'si.e. the Swedish Transport Administration's (STA) − deliberate efforts to engage outlaw innovators in the design of its open data platform.Outlaw innovators are members of the general public who tend to exploit security loopholes to gain unauthorized access to algorithms, hardware and protocols to modify existing systems and, for example, illegal share digital content (Flowers, 2008).They are "driven by utility, curiosity and occasionally even anger, bypassing technical and legal safeguards in their drive to explore" new digital opportunities (Mollick, 2005, p. 21).
Partnering with outlaw innovators is not an obvious choice for public institutions as it has potentially harmful effects on an institution's ability to comply with regulations to which it is held accountable.Also, the hacking practices of outlaw innovators may disrupt a host's digital services or prevent legitimate users from accessing these services.Furthermore, outlaw innovators are frequently reluctant to collaborate with public institutions, preferring to maintain renegade and hacker identities (Schulz & Wagner, 2008).Yet, public institutions can still benefit from outlaw innovation just like many other industries (e.g., gaming, smartphones, and toys) that initially sought to restrict the rogue developers' unauthorized access to and sharing of digital resources, only to later build a synergistic relationship with them (Flowers, 2008;Mollick, 2005).
Given the uncertainties around the potential role of outlaw innovators in accomplishing an open data strategy in the digital transformation of public institutions, we seek to answer the following research question: What principles help public institutions to digitally transform by embracing outlaw innovators in the design of open data platforms?
We rely on a 10-year action design research (ADR) study (Lindgren, Henfridsson, & Schultze, 2004;Sein, Henfridsson, Purao, Rossi, & Lindgren, 2011) led by the first author who headed up a design team of IT specialists at the STA.The mission of the ADR team was to find a way to end the unsanctioned data sourcing of outlaw innovators who scraped that is, programmatically extracted, parsed and exported data from the STA's public websites to develop apps that were popular with train travelers.
Enacted over multiple iterations, the ADR process involved design experiments with prototype platforms that gradually made data scraping unnecessary.In the end, the ADR team built an open data platform (Bonina & Eaton, 2020;Wainwright et al., 2023) whose architecture-governance configuration enabled a highly generative and synergistic public-private partnership between the STA and external app developers.This platform was ultimately deemed so exemplary, that it was adopted for internal use in STA.
We synthesize our ADR study into design principles (Gregor, 2006).While our theorizing deepens the current conceptual understanding of open data platforms, our strategic product and process principles for designing such platforms reveal what it takes for public institutions to embrace outlaw innovators.These design principles have the capacity to assist institutions in mitigating the risks that collaborating with such innovators entails.Specifically, by addressing the tension between public and private interests (Constantinides & Barrett, 2014;Lindgren, Mathiassen, & Schultze, 2021), our principles show that designers of open data platforms need to adopt a both-and orientation (rather than a binary either-or perspective).Public and private views are complementary; they entail one another.
The remainder of the paper is organized as follows.We first conceptualize why embracing outlaw innovators in the digital transformation of public institutions triggers the public-private tension.Thereafter, we characterize open data platforms as a particular class of architecture-governance configuration.We then present the empirical site and outline the research method.In our findings, we report on how STA developed an open data platform together with outlaw innovators over three ADR cycles.In the discussion, we present the three design principles for open data platforms development.Finally, we articulate our research contributions and qualify them in the light of the limitations of the study.

Digital transformation through outlaw innovation
Digital transformation entails organizational change triggered by the proliferation of digital technologies (Hanelt et al., 2021).Tana, Breidbach, and Burton-Jones (2023) view digital transformation as collective social action that is linked to specific goals that participants strive to accomplish by cooperating, collaborating, or interacting with a more extensive network of actors beyond strict organizational boundaries.Mergel, Edelmann, and Haug (2019) suggest that public institutions digitally transform by using emerging technologies to achieve improvements of culture, processes, and services.Besides changing the relationships within the organizations, digital transformation in the public sector also affects the relationship between institutions and citizens as the users of public services.However, public institutions are often too constrained by bureaucracy and risk aversion to effectively leverage the novel organizational designs that digital transformation affords.This incongruence between public sector and digital transformation logics (Hund, Wagner, Beimborn, & Weitzel, 2021;Vial, 2019) give rise to competing concerns (Svahn, Mathiassen, & Lindgren, 2017).
While IS scholars have focused on tensions such as exploitation versus exploration (Magnusson, Koutsikouri, & Päivärinta, 2020), stability versus flexibility (Henningsson & Zinner Henriksen, 2011), and transparency versus privacy (Marjanovic & Cecez-Kecmanovic, 2017), the public-private tension has only recently attracted attention (Bartelt, Urbaczewski, Mueller, & Sarker, 2020;Velsberg, Westergren, & Jonsson, 2020).Likely to surface when there is discord about the appropriate extent of public involvement in private markets or when disagreements arise over resource distribution between the private and public sectors (Constantinides and Barrett (2014), the public-private tension should take into account the multiple and interdependent dimensions of collective action, and not merely concern itself with classifying goods as either public or private.
Outlaw innovationexamples of which include early versions of the Xbox console, the robot dog AiboPet, the iPhone, and Tesla carsis a manifestation of the public-private tension.This unsanctioned (or even illegal) innovation manifests through "non-cooperative, non-consensual relationships in which the user may be unknown to the supplier and in which there is likely to be no free flow of information between the two parties" (Flowers, 2008, p. 178).It may therefore infringe on an organization's intellectual property that is governed by a product's terms of use or ruling laws.While such innovation is often considered a crime (Spagnoletti, Ceci, & Bygstad, 2022), it also has the potential to inspire organizational innovation and renewal (Ulrich, Müller, & Flowers, 2023).
The activities of outlaw innovators, who often have complex and antagonistic relationships with the companies whose products they modify (Braun & Herstatt, 2008;Mollick, 2005), require a wide variety of responses, including legal measures, systematic monitoring, and adaptation or absorption (i.e., incorporating outlaw innovation into a product or service).Whether used in isolation or combination, these responses are rife with paradoxical tensions (Flowers, 2008).For example, it is not difficult to identify and include a few outlaws in the innovation process, but cultivating their value-generating potential in a consistent and productive manner, typically requires a new mind-set on the part of the public institution (Mollick, 2005).
Table 1 summarizes the prior literature on digital transformation in the public sector and indicates outlaw innovation as one of the approaches for accomplishing it.

Open data platforms
Open data refers to digital content that is made freely available to use and redistribute, subject, at most, to the attribution of its source (Jetzek, Avital, & Bjorn-Andersen, 2019).As such, it typically involves making raw, non-personal, and non-commercial dataespecially data that has been collected and processed by government organizationsavailable to the public (Pereira, Macadar, Luciano, & Testa, 2017;Weerakkody, Irani, Kapoor, Sivarajah, & Dwivedi, 2017;Zeleti & Ojo, 2017).Such data is frequently assumed to generate social good by increasing transparency and accountability (Bartelt et al., 2020;Janssen & van der Voort, 2016;Venkatesh,

Table 1
Summary of the literature relevant to our study.

Conceptual foundations
• Literature on digital transformation is diverse and fragmented lacking common definitions.• A recent promising lens builds on collective social action with specific change goals being addressed through cooperation beyond organizational boundaries.

Empirical accounts
• Despite inertia caused by bureaucratic constraints, public institutions find ways to transform by using emerging technologies to improve processes, culture, and services.• Local change efforts in the public sector are often influenced by transformative initiatives taking place at the societal level.(Braa, Sahay, & Monteiro, 2023;Mergel et al., 2019;Scupola & Mergel, 2022)

Paradoxical tensions
• Dilemmas that relate to strategic decisions that revolve around exploitation versus exploration, stability versus flexibility, and transparency versus privacy shape change trajectories of public institutions.• Networked and collective efforts are key to frame and resolve complex issues hampering public change and innovation.

Radical options
• Unsanctioned innovation has the potential to trigger and shape citizenoriented organizational renewal.• Public institutions are hesitant to create such a path because of the unknown, potentially harmful, side-effects it is likely to generate.(Braun & Herstatt, 2008;Flowers, 2008;Mollick, 2005;Spagnoletti et al., 2022;Ulrich et al., 2023) D. Rudmark et al.Thong, Chan, & Hu, 2016), stimulating innovation and enhancing citizen participation (Magnusson et al., 2020;Olphert & Damodaran, 2007;Rosenberger, Lehrer, & Jung, 2017), as well as enhancing social justice by allowing individuals greater control over their lives and improving their social and material conditions within the structures of societal privilege where they reside (J.Johnson, 2014).While open data platforms can be considered as a specific class of digital platforms that enables formation of novel public-private ecosystems (Hein et al., 2023;Lnenicka et al., 2024;Wainwright et al., 2023), we seek to provide insight into the actions of these platforms to assist open data exploitation by outlaw innovators.Our specific objective is to learn how such a platform's core architecture can be composed of modules of datasets (rather than functionality) that these innovators (as well as other external developers) may access to combine and integrate them in innovative apps and services (in the peripheral architecture) for citizens to consume.We synthesize and extend the received theory on digital platforms (Gawer, 2014;Saadatmand et al., 2019) focusing on architecture and governance as building blocks for the configuration of open data platforms (Bonina & Eaton, 2020;Hein et al., 2023).We next conceptualize each of these elements in turn to articulate our initial kernel theory that informed our ADR study (see Table 2 for a summary of our kernel theory).

Technology architectures
An open data platform is expected to transform a public institution's data resources so that they match citizen needs.Here, the platform architecture constitutes the necessary means to reorganize incumbent resources and redistribute design capabilities to external innovators/developers.As such, it consists of a stable core, standardized visible interfaces, and peripheral applications (Baldwin & Woodard, 2009;Karhu, Gustafsson, & Lyytinen, 2018;Saadatmand et al., 2019).To enable seamless additions of new data resources, the core is modular and reflects the principle of information hiding (Parnas, 1972), which stipulates that a designer of modular systems has to ensure that only necessary information is available for the module users to reduce dependencies and accommodate change better.
A module's visible information that users can act on has been conceptualized as design rules by Baldwin and Clark (2000).While these rules stipulate in what ways module developers can establish compatibility with the platform, a complete set of rules consists of a blueprint describing the modules of the architecture, the interfaces of these modules, and accompanying integration protocols and testing standards that allow a developer to integrate his/her app with the platform (Baldwin & Clark, 2000).By relying on the rules, a designer may reorganize modules to achieve the desired platform capabilities.Such reorganization corresponds to the design rules architecture and constitutes what visible modules that external developers can interact with (Jha & Pinsonneault, 2016;Kapoor & Agarwal, 2017;Kazan, Tan, Lim, Sørensen, & Damsgaard, 2018).Baldwin and Clark (2000) suggest that modular operators play a crucial role within any modular systems.These operators act as a

Table 2
Summary of our kernel theory components.

Insights Sources
Open data platforms • Digital content freely available for use and redistribution leverages citizen engagement in a sharing society.• Non-personal, non-commercial data collected by government organizations must be available to public and private actors alike.• Platforms for generating social good by increasing transparency, stimulating innovation, and enhancing citizen participation are still rare.• Boundary-spanning platforms for data-driven processes rely on increasingly complex architecture-governance configurations.(Bonina & Eaton, 2020;Gawer, 2014;Janssen et al., 2012;Jetzek et al., 2019;Johnson & Robinson, 2014;Pereira et al., 2017;Saadatmand et al., 2019) Technology architectures • A well-functioning platform architecture consists of a modular core, visible interfaces, and peripheral applications.• Design rules and modular operators play key roles by specifying how developers can interact with the platform and accommodate changes.• Integration protocols and testing standards allow developers to connect their applications to the platform, thus minimizing coordination costs.(Baldwin & Clark, 2000;Baldwin & Woodard, 2009;Karhu et al., 2018;Tiwana, 2014) Governance mechanisms • Recent governance models focus equally on search mechanisms and platform openness.• Stability is maintained through coherent search strategies, while flexible searches pave the way for expansion into new territories.• Platform openness can be achieved via access openness (i.e., selected parts of the platform are made accessible) or resource openness (i.e., intellectual property rights are forfeited).• Boundary resources (e.g., APIs, SDKs) and license terms are at the heart of attempts to govern external development projects.(Boudreau, 2010;Brunswicker & Schecter, 2019;Ghazawneh & Henfridsson, 2013;Karhu et al., 2018;Saadatmand et al., 2019;Tilson, Lyytinen, & Sørensen, 2010;Wareham et al., 2014) D. Rudmark et al. discrete set of possibilities for how a designer may alter a modular system's architecture.By inverting, a designer may create modules that implement widely used or requested functionality within an ecosystem.By substituting, a platform designer may replace existing modules with improved qualities.By mutating, modules are copied for usage in other application domains (Karhu et al., 2018;Tiwana, 2014).Design rules also require visible interfaces that specify module behaviors within the platform.These interfaces serve as a description of what the platform affords for developers (Parnas, Clements, & Weiss, 1985), thus conveying the boundaries of possible platform innovation.
Finally, design rules deal with the use of integration protocol and testing standards.This concerns the necessary information developers need to connect the platform's core interfaces with those of the complementary app's micro-architecture.Such information includes SDKs, IDEs, or code examples that help developers during the design of their application, e.g., by providing entry paths for new platform developers (e.g., code examples), simulating the runtime environment, or ensuring compatibility with specific devices (Evans, Hagiu, & Schmalensee, 2006;Tiwana, 2014).In this way, platform complexities (Cennamo et al. 2018) can be encapsulated to minimize developers' coordination costs (Tiwana, 2015).

Governance mechanisms
In the realm of open data, a platform owner's focus concerns two governance decisions in particular: 1) what the platform offers in terms of solution search mechanisms; and 2) how open a platform is to external innovators/developers.The first decision deals with how a platform can both maintain stability and at the same time allow for expansion into new territories (Kapoor & Agarwal, 2017;Saadatmand et al., 2019;Wareham, Fox, & Cano Giner, 2014).To maintain stability, developers may enact a coherent search strategy, which refers to a developer being guided by past experiences and known solutions to prevalent problems (Brunswicker & Schecter, 2019).Such guidance helps developers to identify solutions characterized by stability and reuse potential.However, while coherent searches promise to maintain a platform's stability, a too one-sided focus on such searches can hamper changes in the ecosystem necessary for the platform to stay competitive.In contrast, a flexible search strategy refers to developers who explore novel solution spaces to meet anticipated future needs (Brunswicker & Schecter, 2019).
The second core aspect of open data platform governance concerns how to open up a platform for outside access.The literature offers two principal strategies to achieve platform openness, namely access openness and resource openness (Boudreau, 2010;Karhu et al., 2018).When a platform is opened by offering access to selected parts of its core, the platform owner may choose what parts of, in what form, and under which intellectual property regime external developers can use the platform.In this way, it affords the owner additional flexibility on its future use trajectory.When governing external development this way, boundary resources play a crucial role (Ghazawneh & Henfridsson, 2013) in that they constitute the thin layer of assets that both capacitate and confine contributions from external developerssuch as APIs, SDKs, license terms, and testing tools.In contrast, resource openness is defined as opening the platform's valuable resources by forfeiting their intellectual property rights (Karhu et al., 2018).As such, this strategy is closely associated with platform governance that makes a platform core readily available to users.A platform owner may achieve greater uptake as legal barriers to reuse have been removed, but also has limited means of controlling the continued evolution of the platform.

Method
We employed ADR (Sein et al., 2011) to address our research question.In using this method, researchers collaborate closely with practitioners to resolve prevalent problems through artifact design and simultaneously produce sufficiently generalized design knowledge for reuse in other design contexts.More specifically, ADR projects are expected to generate three types of contributions: ensemble-specific and end-user utility contributions, which are geared toward practitioners, and design principles, which contribute to Fig. 1.Data retrieval prior to ADR cycles (sanctioned data solid line, unsanctioned data dotted line).
Our research site was the STA, a national governmental agency, whose mission was the long-term strategy and planning for all transportation modes as well as overseeing the construction, operation, and upkeep of public roads and railways in Sweden.While it managed both the digital and physical infrastructure components for railways, its primary customers included citizens and train operators.Our ADR project, which was kicked off in January 2012, was prompted by travelers' increasing use of third-party mobile train schedule apps, relying on the unauthorized use of STA's digital infrastructure (see Fig. 1).In particular, there were a number of mobile apps, written by independent developers whose own needs as train commuters had driven them to develop an app, which scraped near-real-time train data from STA's schedule web page (see Table 3).STA found this situation problematic because these apps built on unsanctioned data access were prone to breakdowns that ultimately reflected badly on the institution.
ADR consists of four distinct stages that are guided by seven principles.The first stage, problem formulation, involves identifying and scoping research opportunities, setting roles and responsibilities, agreeing on the focus and mode of inquiry, and draws on two principles.First, practice-inspired research entails starting with problems in practice, considering them as research opportunities.In our case, we chose the STA's problem with data scraping by outlaw innovators as our point of departure.We noted generalizability opportunities allowing us to cast the specific issues into a more general class of problemsspecifically, designing open data platformsand developing corresponding design principles (Iivari, 2015).Second, theory-ingrained artifact refers to how researchers inscribe theories into the designed material.We analyzed STA's challenges associated with scraping activities using Flowers (2008).Our initial alpha artifact was shaped by the emerging literature on digital platforms (Baldwin & Clark, 2000;Boudreau, 2010;Tilson et al., 2010;Tiwana, Konsynski, & Bush, 2010).However, our subsequent theorizing and the further development of our kernel theory leveraged more recent platform contributions on architecture-governance configurations (Brunswicker & Schecter, 2019;Gawer, 2014;Karhu et al., 2018;Saadatmand et al., 2019).
The building, intervention, and evaluation (BIE) stage of the ADR cycle involves building an IT artifact, evaluating it in the use setting, and refining it iteratively.This stage is governed by three principles.First, reciprocal shaping highlights the mutual molding between the IT artifact and the surrounding organizational ecology (Orlikowski & Iacono, 2001).We applied this principle by evolving the open data platform with an understanding of the STA and the outlaw innovators' life-worlds.Not surprisingly, this principle led to the design of not only multiple IT artifacts, but also organizing processes.Second, mutually influential roles principle emphasizes that researchers and practitioners should jointly shape the result (McKay & Marshall, 2001).In the alpha phase of our project, design suggestions were driven by researchers, while both the STA and external developers provided feedback to the design.The beta and release phases closely followed the ideal model in that the ADR team involved both researchers and practitioners.Third, the authentic and concurrent evaluation principle was applied throughout our project and included naturalistic evaluations (Venable, Pries-Heje, & Baskerville, 2016) like joint workshops, online discussion forums, and live platform usage.
Following the BIE stage in the ADR cycle, researchers engage in the reflection and learning stage, which demands conscious reflection on problem framing, chosen theories, and the emerging artifact.This stage draws on guided emergence as the interplay between conscious design decisions and environmental structures (Purao, 2013).This interplay characterized our research throughout; while some initial hypotheses of architecture-governance configurations (e.g., those related to coherent search mechanisms) were validated, insights from our situated empirical evaluations sparked substantial redesign in response to initial structural misalignments such as public-private tensions.Accordingly, these platform configurations materialized our interventions, evolved over the ADR cycles, and served as a foundation for the development of the final set of design principles.
The final stage of an ADR cycle concludes with formalization of learning, which entails abstracting learning, sharing outcomes, and formalizing results for dissemination (Gregor & Hevner, 2013).As such, its goal is to derive generalized outcomes.We have relied on this principle to synthesize generalized product principles as part of our design theorizing.In addition, our theorizing included processoriented guidance for designers consistent with a design-theoretical tradition (Li, Sun, Chen, Fung, & Wang, 2015;Markus, Majchrzak, & Gasser, 2002;Walls, Widmeyer, & El Sawy, 1992), which emphasizes the necessity of providing such guidance to help designers meet their objectives.
With regard to the initiation of the first ADR cycle (Jan 2012-April 2012), applying the principle of practice-inspired research, a researcher-client agreement (Davison, Martinsons, & Kock, 2004) between STA and the first author, who at the time was with RISE Research Institutes of Sweden (a non-profit research institute in Sweden), was signed.This agreement outlined the problem that the ADR project would help resolve and committed to STA's cooperation in an initial pilot project on whose success STA's further cooperation would depend.The pilot ADR team, consisted of the first author and a product manager at a public-private partnership, Trafiklab, facilitating the digitalization of the Swedish public transport sector.The two-person team developed a first blueprint for an open data platform that was presented to STA in April 2012.The platform design was informed by interviews with key personnel at the STA about current strategies, challenges, and plans within the administration, the identification of the most popular third-party trainschedule apps, and interviews with their developers (see Table 4 for a summary of data collected).The analysis of the interview data yielded primarily a list of design requirements for a platform through which rail data would be made available to external developers.However, the interviews also highlighted the distrust between the STA and such developers.In view of these insights, drawing on extant contributions on digital platforms (Baldwin & Clark, 2000;Boudreau, 2010;Tilson et al., 2010;Tiwana et al., 2010) and outlaw innovation (Flowers, 2008), the ADR team crafted a conceptual design for the proposed open data platform (see Appendix 7) that was discussed and evaluated during a workshop.The attendees included nine key STA stakeholders (including the responsible manager), the strategist in charge of external data sharing, and the IT object owners overseeing train data.Four distinguished outlaw innovators, known for creating popular apps or APIs related to train data, were also present.Based on this ex ante formative evaluation (Venable et al., 2016), STA gave the green light for the continuation of the ADR project.
For the second ADR cycle (May 2012-January 2013), the ADR team grew to six people covering the first author, who acted as team lead, a product-and systems-manager and a systems architect from Trafiklab as well as two systems managers and a systems developer from the STA.Building on platform search theory (Brunswicker & Schecter, 2019;Tilson et al., 2010) a beta version of the emerging open data platform took the form of a data sharing infrastructure that offered two APIs: one for known coherent searches (Brunswicker & Schecter, 2019), which supported frequently implemented use cases (e.g., to get all departures from a given station) and another for non-deterministic flexible searches (Brunswicker & Schecter, 2019), which enabled access to unprocessed underlying information objects.
The platform specifications were made public and external developers could provide their feedback through an online discussion forum.Simultaneously, the beta solution was built and delivered in October 2012 via Trafiklab's API publishing infrastructure.Anyone could register for access to the APIs and within three months a total of 59 developers had requested them.In an effort to evaluate the open data platform, the first author contacted all registered developers to request an interview.As a result, feedback from 17 developers was collected (see Table 5 for a summary of data collected).
The third ADR cycle (April 2013-August 2014) was initiated when STA influenced by positive developer feedback committed to further develop the beta platform version into a permanent open data solution.The objective of this cycle was to build a release version that could be an integral part of STA's production environment.Hence, the platform initiative changed status from a research project to an STA IT project and full-time employees of the institution's IT organization took over leadership for its execution.The first author still continued to serve as a fully-fledged member of the ADR team, acting as co-designer with responsibility for conducting situated evaluations of the emergent open data platform.
As part of the continued ADR effort, additional feedback from persistent outlaw innovators meant that the design of the platform was yet again adapted.Because the new design exhibited increased complexities, particular attention was given to requirements of novice app developers with little knowledge of rail transport.By means of a usability test, which was run in December 2013, the ability of 13 test subjects (second-and third-year students majoring in IS) to perform three taskslocate data, call APIs, and build a crude applicationwas assessed.A key insight from this test was that those coherent searchespredefined queries that provide the necessary data for a given functionality, such as checking the status of a specific trainwere imperative to user productivity.
We also compared our interventions with experiences from other Swedish public transport agencies by analyzing third-party apps to determine if their data came from scraping or APIs.Although these agencies now had APIs, they had previously been subjected to scraping.Out of 19 working apps using real-time data, 5 were still based on scraping, thus strengthening our hypothesis that our new design with a stronger alignment with developer needs was necessary to stall scraping.
In February 2014, the platform was launched as an open test environment.Any user registered for the STA's new platform could use the API.While twenty developers in fact registered (several of which were outlaw innovators, beta version testers, or both), six of them agreed to be interviewed.Their feedback was taken into consideration and incorporated before the open data platform went live on March 18, 2014.The third ADR cycle was concluded with another round of interviews, which included six app developers as a summative evaluation ex post (Venable et al., 2016).Refer to Table 6 for a summary of data collected in this phase of the research.
After the ADR project was terminated and the first author had left as active designer of the STA's open data platform, the research team continued to follow its trajectory and collected post-hoc data using different techniques (September 2014-April 2021).In September 2016, a data source experiment, following the same procedures used in the second ADR cycle, was conducted to investigate the actual data sources.This time, however, the experiment included apps using railway data from the STA.For apps whose data source could not be determined programmatically, team members instead reached out to the app developers (five developers managing a total of 11 apps) to collect such information.This assessment revealed that among the 28 smartphone applications, all retrieved data from sanctioned channels.Hence, it could be concluded that the development approach pursued by the ADR project had been successful.Additionally, when a new open data infrastructure for the entire Swedish public transport industry was considered in 2017, this approach became the role model for resolving service level agreements.As a final data collection effort, taking place between October 2018 and April 2021, the first author carried out a follow-up study that involved, first and foremost, interviews with four actors playing key roles in executing STA's new open data platform strategy.The objective was to inquire into what had happened with the platform and how it had evolved since its launch by analyzing the change logs.Statistics of the platform's usage were also collected.Being led by the first author, the team of researchers concluded this last phase of the ADR study by formalizing the learning it had generated and articulating design principles and their theoretical implications (Sein et al., 2011) (see Table 7 for a summary of data collected).

ADR cycle #1: Conceptualizing developer requirements (January 2012 -April 2012) Problem formulation
By the end of 2011, many train-related mobile apps relying on scraping were available to travelers.Ironically enough, one of these was even installed by default on all of the STA smartphones.These apps were written by outlaw innovators who had been driven by their own train travel needs, as the developer of one of the leading smartphone apps explained:

For those of us who travel every day, it becomes very frustrating to sit and not know when to get home… not to get this information. […]
There could be hour-long delays several days a week, so I sat down with my laptop and started to scrape this information and make it more accessible.
To understand the more precise data needs of these outlaw innovators, existing app designs were scrutinized by the ADR team and it was revealed that these designs covered a relatively standard set of use cases.They included searching for a station based on a search string, getting departures/arrivals information from a station and platform, and getting a particular train's status.The data to implement this functionality were scraped in three ways (see Fig. 1).The first, entailed relying on an obscure web page that has been designed for mobile use.Due to its minimalistic use of HTML, this page was easy to parse and re-process.Accessing data through a JavaScript interface became the second option when the STA introduced a dynamic web service, which was intended for internal use only.This web service inadvertently provided an API that made various transport-related datasets available to external parties.The API used a flexible query language accessible through JavaScript and in the absence of clear interface specifications, outlaw innovators had to figure out its information model through trial-and-error.Eventually, two of these innovators reverseengineered the API and made instructions for its use public (see Appendix 5).Many more, including inexperienced developers, could thus leverage the API in designing their apps.The third form of data scraping was based on APIs that provided access to scraped data that two outlaw innovators had initially developed for their own use (see Appendix 6).These APIs were also limited to the most popular use cases: I've published this API because of the massive effort I've put into getting some useful data out of this messy, underlying dataset so that no one else will have to do it again.I'm just a single individual and I can't possibly do all apps for all platforms or services or whatever it may be that people need.
The STA considered the screen scraping through which the outlaw innovators sourced the train data as problematic; the apps mediated the STA's relationship with their end-user passengers in such a way that the STA had no control over the digital representation of its service.Furthermore, the scraped interfaces were notoriously fragile and subject to change that periodically caused third-party apps to malfunction, which in turn, invoked passenger annoyance.But since the developers remained anonymous, the STA was unable establish cooperative relationships with them such that app problems could be addressed: We don't know who these people are and we don't get any feedback.It's much better to have a relationship [with the outlaw innovators] for both parties… where we can negotiate each party's liabilities and resolve issues as they occur.(Head of Traffic Information services, STA) Even though STA's leadership expressed a serious desire to develop cooperative relationships with the outlaw innovators, they nevertheless referred to them in denigrating terms, including "railway nerds", "underpants hackers", and "non-professional students".The ADR initiative was prompted by an appreciation on the part of the STA that productive working relationships with the outlaw innovators needed to be developed, as expressed by the STA strategist in charge of formulating a strategy for open data: We need to understand what needs developers have when it comes to things like formats, delivery qualities, and content.We also need to know why they need this to understand the actual value of delivering data in a better way.
However, in its decision making, the STA was constrained by a key legislated rule, namely that public funds could not be used to take value-creation opportunities away from or create advantage for any private sector service provider.A senior strategist at the STA explained:

If you imagine a company with a special interest in a simpler [data] format. […] Is it our role to start building APIs for them? I would say 'absolutely not.' Because we would steal money from other [competing] companies, while being funded by taxpayers' money.
On the other hand, the users currently relying on privately administered APIs based on scraped data, found that situation problematic:

It's always a bit nerve-wracking when it's a private individual behind an API… you don't know what's going to happen with it. Will he shut it down or keep it running?(Developer A4)
When the ADR team asked about what outlaw innovators would like to see in APIs provided by STA, they stressed understandability and simplicity to expedite development:

Some companies expose their entire domain model to third parties. And I'm sure their domain is super clear to the company, but not really understandable to anybody else. (Developer A3)
Additionally, they sought data relevant to functionality that helped passengers to solve their train-travel problems.Most outlaw innovators therefore wanted APIs that supported common use cases:

What's important to me is that the API reflects the use case − starts from what most users want to do such as travelers who need to travel from point A to point B (Developer A4)
The ADR team concluded that the primary problem STA experienced was its oppositional relationship with outlaw innovators, manifesting as a public-private tension.While the STA realized that they needed to build cooperative relationships with these innovators, they also belittled their status as technologists with whom they could partner to accomplish the digital transformation imperative.Such cooperative agreements also needed to comply with the legislation that, as a public institution, the STA could not reduce the value-generating potential or increase the competitive advantage of any commercial actor.From a technological perspective, the ADR team noted that STA lacked the data delivery mechanism that could support reliable third-party apps.

Building, intervention and evaluation
The ADR team envisaged a platform through which external developers could access data using APIs.Its efforts focused on building such platform solution.By relying on the ADR team as an intermediary to identify the outlaw innovators' requirements and solicit their D. Rudmark et al. feedback during the development of an open data solution, the ADR team reasoned that the mutual interests of the parties would evolve and a more egalitarian relationship between them would emerge.The platform's blueprint was based on Trafiklab as a public-private platform that disseminated data from public transport agencies.It consisted of a layered, cloud-based software architecture.By adding a new layer to Trafiklab's platform infrastructure, external developers were given an API-based interface that afforded them access to coherent searches, i.e., a discrete bundle of data that supported a common use case such as listing the train departures for a given station.
This coherent search API presented some advantages for the emergent mutualistic relationship.First, it reduced the amount of sector-specific domain knowledge that external developers required to build a train travel app.Second, by leveling the developer playing field, the STA was at less risk of engaging in behavior that could be construed as providing undue advantage to some commercial actors.Third, the interface design was modeled on the unsanctioned APIs that had been in use previously, thus minimizing the STA's intervention in the app ecosystem.
From a technical point of view, the datasets needed to be pre-processed and cached to limit the processing burden of apps interfacing with STA's operational infrastructure.Appendix 7 represents the conceptual architecture, which was presented to the STA and prominent outlaw innovators during a workshop in April 2012.
Overall, the workshop participants' responses to the conceptual design were positive, yet also somewhat critical of certain platform design aspects.Some two weeks after the workshop, the ADR team adapted the blueprint for the open data platform that addressed the participants' concerns.This new blueprint was submitted to the head of Passenger Information at the STA who then gave the go-ahead to develop a functional prototype of the platform: i.e., to proceed to a second ADR cycle.

Problem formulation
The outlaw innovators' primary critique of the open data platform design was that coherent searches represented the only way of accessing data.It was the more experienced innovators, in particular, who wanted access to more raw data so that they had the flexibility to innovate rather than be constrained by established use cases.Also, for such raw data, more cohesive formatting had priority over the understandability and simplicity of the data.These innovators voiced their frustration with the platform's alpha design during the workshop:

Would be super happy if that freaking HTML is simply transformed into XML so that everything looks exactly the same. That would be enough for me. […] Don't think it must be so damn advanced [e.g., processed for specific use cases]. (Developer A2) Want an API to present more exhaustive data that don't have to be easy to understand. Would rather like a focus on correctness and structure. (Developer A1)
The ADR team summarized the problem that the second cycle needed to address as follows: for established, common use cases, developers benefited from pre-processed bundles of data (i.e., coherent searches); but to innovate and develop novel use cases, developers also needed to be able to access a wide variety of raw data in an ad-hoc manner (i.e., flexible searches).The STA's open data platform thus needed to include both capabilities, which was challenging from a technical point of view (i.e., it would significantly increase the data load for the STA's legacy systems), as well as from an organizational standpoint (i.e., processes to assure data quality and security).While the STA controlled the data that was accessible through the flexible searches, allowing external developers to Fig. 2. Data retrieval after ADR cycle 2 (sanctioned data solid line, unsanctioned data dotted line).
D. Rudmark et al. access the database for such searches required a stronger sense of trust and shared interests, e.g., mutualistic interest in improving digital services to train passengers.

Building, intervention and evaluation
The ADR team formulated the system requirements for flexible and coherent searches across all train scheduling data and started detailing a new platform architecture that required the integration of multiple platform elements (see Appendix 10 for details).A new app-facing module that was made available via cloud-based service hosted by ApiGee, a company selling platforms that host and scale APIs, was made available.This new module decoupled flexible and coherent searches from STA's production environment, in that it handled access control, cached data to limit query redundancy and the processing burden on STA's production system.It also provided the two new interfaces, TrainInfo (see Appendix 8) and TrainExport (see Appendix 9).In other words, the API-hosting platform ApiGee was used to materialize the inverting modular operator, which rendered new interfaces, channeling the coherent and flexible searches from STA's systems and delivering them to the apps in a format that matched developer preferences (see Fig. 2).
In their feedback on the emerging platform design, the external developers requested an API that would deliver any data that had changed since their app's last API call: It would be great if each line could have a timestamp that says when the line was last modified, corresponding to "UpdatedTime" in KartDB.messages.You're often interested in what has happened since the last known time and today there's no reliable way to make such selection from Orion.
Given the STA systems' architectural constraints, this data could not be generated.On the current platform, Orion, the entire snapshot of the database was refreshed periodically, not just the records that had changed since Orion's last update.Building the new requested capability was cost-prohibitive given the project's budget.
The open data platform was completed with an API console, a development environment where users can explore APIs without integrating them into their apps.Finally, the platform included the ability to grant API keys upon user registration, a brief tutorial on using the platform, as well as documentation of the data models.This development environment reflected the significant shift in the relationship between the STA and the outlaw innovators, as the STA sought to help the external developersespecially those with little development experienceto explore and implement new use cases.

ADR cycle #3: Implementing developer queries (April 2013 -August 2014) Problem formulation
The open data platform pilot produced by the second ADR cycle convinced the STA of the feasibility and potential value of freely sharing its data with external developers.The change in STA's orientation towards collaborating with the outlaw innovators was apparent in this comment from a project manager: It became evident to us that we needed to recognize the diversity of actors.We saw that if we made it easy to use our data, there were so many who could make use of it.But precisely who these would be was difficult to predictit could be a third-party supplier that we never heard of who did something extraordinary.[…] So, let's make it really easy to use our data so that it actually becomes something [more valuable].
The STA's commitment to an open data strategy to transform itself digitally was instantiated by creating a new stakeholder grouping for the outlaw innovators.A fourth customer segment, denoted basic, was added to the three extant groupings: i.e., complete (for rail operators and transport agencies); societal (for society-critical functions); and extended (for larger software houses and information brokers).This new segment was subject to the STA's general terms of system use, entitled to rudimentary assistance in the form of FAQ and web-based support, and given access to "simple, basic information products".
The legitimation of the outlaw innovators as potentially strategic partners meant that the pilot platform needed to be scaled up and implemented in STA's production environment.The leadership for the release version of the open data platform was thus taken over by project managers from STA's IT department.While the evaluation of the pilot platform by external developers highlighted relatively minor bugs (e.g., difficulties retrieving the API key), most users of the TrainInfo module reported a satisfactory experience:

TrainInfo is excellent. It was quick to get started and find the information you needed to figure out a solution to your problem. Don't think that STA needs to change a thing. (Developer B13)
However, developers that had relied on screen scraping in the past tended to be disappointed with the API-based mode of data delivery and therefore chose to continue with their unsanctioned data access methods: We're still using the unofficial API that STA exposed so we haven't switched to these other TrainInfo and TrainExport APIs.The reason was that we already set up our services to get that data and were already kind of tied to that API.It would mean just more work to switch.(Developer B3) The problem that the third ADR cycle needed to address was thus the reluctance of experienced developers to migrate away from their reliance on scraped data (see Fig. 2).In light of some developers' claims that "there is nothing [in the open data platform] that attracts me" (Developer B14), the STA project team concluded that the value proposition of their comprehensive and flexible searches needed to be made more apparent and appealing.One way of accomplishing this was to develop an API for accessing the records that had been altered since the last time the app accessed the data.At present, the developers had to identify these changes themselves D. Rudmark et al. through a laborious process that entailed downloading a complete snapshot of all running trains in Sweden and then write an algorithm that detected any potential changes since their last search request.

Building, Intervention, and evaluation
To add this new functionality, the development team made fundamental changes to the architecture of the release version, which was called "DataCache."By implementing a query language that STA used internally to retrieve data, the outlaw innovators that continued to screen-scrape had the capability to write and execute more specific searches to produce more distinctive apps.However, since the query language was designed for internal use, it was redesigned to reduce redundancy, disambiguate and simplify syntax, and strengthen data model congruence.This rendered it more robust for users who had little to no understanding of the STA's underlying systems (see Appendix 11 for details).Through the query language, the platform afforded not only access to all data, but also the ability to mix and match in novel and unique ways.
With the new query language, the infrastructure for coherent searches used in ADR cycle 2 was lost.However, it was implemented as predefined sample queries: e.g., the departures from a given train station, which developers could use as a starting point for accessing the data they needed.These samples could then be expanded according to the specific needs of the app.
A 'ModifiedTime' field, indicating the latest update of a data entry, was added to the information objects in "DataCache".Furthermore, design innovations developed in the pilot version of the platforme.g., the API console, documentation, and example API callswere also incorporated into the release version of the open data platform (see Appendix 12 for an overview of the architecture).
The development team also took the radical step of designing the platform not just for external developers but also for the STA's own internal use.By aligning the interests of the public institution with those of these developers, the STA ensured that its investments in the platform benefitted the institution, the app developers, andmost importantlythe travelling public.With the STA and developers having the same data infrastructure (by the substituting modular operator), the number of platforms and interfaces that the STA would have to maintain over time was significantly reduced.Furthermore, the STA's interests in the quality and accessibility of data were aligned with those of the external developers, all of which benefited the public.

Follow-Up Study: Exploring developer outcomes (September 2014-April 2021)
In September 2016, the actual data sources used for all train-scheduling apps was investigated (see Appendix 13).It showed that the use of unsanctioned interfaces (e.g., screen scaping) had ceased (see Fig. 3).At the time, 28 services for smartphones using real-time information were available in the application marketplaces (e.g., Apple AppStore).Out of the 28 real-time services, 19 used DataCache's open API, six used interfaces connected to other STA external developer segments (a system called UT/IN), and three were not operational.
Moreover, DataCache's usage statistics showed that the user population was a good mix of established and new developers.As summarized in Table 8, new developer registrations had stayed relatively constant since the DataCache's launch, reaching a total of 5727 registered developers by August 2020.Additionally, external API calls had increased over time, from some 20 million in early 2016 to some 100 million per month in 2020 (see Table 8).External use had handily eclipsed internal use.The study also investigated STA's internal use of the platform.Until 2015, DataCache had been deployed just once, serving both external developers and STA's public end-user services.But in 2015, the team responsible for DataCache proposed its use for an internal project, placing the platform at the center of various system integration efforts (by employing the modular operator mutating), e. g., data sharing across STA's internal traffic information systems (see Fig. 3).As the systems architect of DataCache highlighted, the platform significantly improved the STA's ability to develop solutions for their users: They come to us and say 'here's our data'.Then we do our magic and suddenly they've a service up and running in a couple of days that would have taken half a year to build before.
In light of these dramatic improvements in STA's ability to deliver IT solutions, DataCache became the institution's official integration platform in 2020, ahead of commercial alternatives.

Discussion
Public institutions are increasingly under pressure to make their data freely accessible in machine-readable form to increase transparency, civic engagement, innovation of public services, and social benefits (Hein et al., 2023).However, for a number of reasons, including inadequate data quality (i.e., inaccurate, incomplete, outdated information), misalignment between the open data and the data required to produce meaningful digital services for citizens, as well as citizen's inability to generate meaningful insights from the open data, many of these open data efforts to digital transformation in the public sector tend to fail (e.g., Chen et al., 2023;Gascó-Hernández et al., 2018).
In this paper, we report on a successful open data platform employed by the STA.Prompted by illegal scraping activities enacted by outlaw innovators who developed train schedule apps that were highly popular with the traveling public, the public institution took the somewhat unusual step of embracing these innovators into its own initiative to build an open data platform.By providing the external developers with the data that they needed for their apps, the unwanted scraping ceased.
However, embracing outlaw innovators is not without risk.Examples from the private sector, including the Xbox gaming console (Schäfer, 2011, pp. 81-91) and the iPhone (Ghazawneh & Henfridsson, 2013), underscore that once the outlaw-innovation derivates propagate into the user base, it is difficult to shut down the apps and reclaim the market.Additionally, even when an entity subject to scraping activities tries to cooperate with outlaw innovators and bring them into an organization-sanctioned ecosystem in which distributed innovation is encouraged, such innovators may resist cooperation and persist with their illegal data sourcing (Eaton, Elaluf-Calderwood, Sørensen, & Yoo, 2015).
In this research, we provide insights into how these risks can be managed in the public sector.Consistent with the expectations of the ADR method, our project makes contributions that are relevant in both practice and theory (Sein et al., 2011;Westin & Sein, 2015).These are captured in three design principles.

The principle of aligning around citizen focus
The STA's approach to meeting the public's demand for open data entailed developing not only an open data platform, but also an ecosystem of distributed innovation.In this way, travelers' access to public train data was mediated by app markets, which the STA was unable to provide.However, creating and managing such an ecosystem of intermediaries was challenged by the tension between public and private interests (Constantinides & Barrett, 2014;Lindgren et al., 2021).In the case of STA, this took the form of outlaw innovators finding ways of illegally sourcing the data they needed for their apps, thus threatening the integrity of the STA's data infrastructure.
For the digital transformation of the public sector to be successful, as in the STA's case, the public-private tension must be resolved.This requires dialectic management (Van De Ven & Poole, 1995), which entails synthesizing the opposing views of the public institution and the external developers (including outlaw innovators).The path to synthesis evident in STA's development of the open data platform took the form of transcendence (Putnam, 2015), which entails reaching beyond the public-private conflict by identifying a shared interest.This shared interest revolved around serving the ultimate customer of the open data, namely the traveler.
With regard to the STA, which was beholden to the public and whose focus is the public good, aligning around providing value to the traveler meant that it was interested in collaborating with the outlaw innovators and providing them with the data they needed to provide the best and most reliable services to the public.In other words, the STA was willing to invest resources that it initially deemed onerous and developed a new data platform infrastructure, namely DataCache, which allowed the outlaw innovators to download just the data that had changed since their app's last data retrieval.In this way, STA was able to bring even the holdout outlaws into their novel innovation ecosystem.Focusing on the traveler made economic sense for the outlaw innovators too.By distinguishing their apps and offering differentiated value, they improved their respective product's market position and the potential to monetize their development efforts.We conclude that conflict over the public versus private interests should be synthesized through transcending to a higher-level goal, namely providing value to citizens/customers.

The principle of catering to the data needs of heterogenous developers
As the ecosystem of outlaw innovators showed, the community was diverse in terms of innovators' interests and skills.Not only did they rely on different scraping sources, but there were also those who relied on the data that more sophisticated developers had scraped, cleaned, and shared.Additionally, some outlaws were motivated to build the apps to solve their own travel needs, whereas others saw this development space as a business opportunity.Even though it took three design iterations, STA's approach to the development of the open data platform was ultimately to accommodate the heterogeneity of developer needs.Initially, only the functionality for coherent searches to support specific use cases was developed (Brunswicker & Schecter, 2019).The intention was to make external app development easier to a broad base of innovators.When the feedback from more sophisticated outlaw innovators highlighted the insufficiency of this constrained access to the public data, the ADR team added flexible search capabilities to the platform design.In addition, the team made a development environment available to external developers to provide them with more support as well as reasons to abandon illegally scraped data sources.
However, it was only whenafter considerable resource expenditurethe STA provided outlaw innovators with data that only the most experienced among them could retrieve via scraping that the holdout outlaws saw the benefit of relying on the open data platform alone.We derive from this experience the principle that open data platforms need to cater to the heterogeneous data demands of external developers if they are to stop illegal scraping activities by outlaw innovators.When the DataCache platform was made available, the last outlaw innovators joined the community of developers that STA sought to leverage to accomplish its digital transformation driven by open data and thus serve the traveling public better.

The principle of maintaining a single data platform infrastructure
The most surprising outcome of STA's open data platform development efforts was that the institution itself eventually started to rely on it.Instead of maintaining two infrastructures for train-related informationone internal and one outward-facing one -STA adopted an "eat-your-own-dogfood" stance.This helped the STA, as a public institution, to live up to its fiduciary duty towards citizens; it is simply less costly to maintain only one infrastructure.Additionally, it left no doubt about the institution's commitment to open data; if it relied on the DataCache platform itself, how could it hide any train-travel data?STA's move to a single data platform infrastructure (a situated morphing of the resource openness strategy (Karhu et al., 2018) further highlighted the extent of the institution's digital transformation.It had established a community of external developers to which it provided the same data and platform functionality that its own developers sought.This solidified the partnership with the community of external developers by demonstrating that the STA recognized their value in completing the institution's digital services to the traveling public.In light of the respect the STA accords the external developers by limiting its own IT organization to the open data platform, it is not altogether surprising that there is no scraping-based outlaw innovation apparent any longer and that the DataCache platform is held up as exemplary in the rest of the STA.

Contributions
Our research shows that the digital transformation of public institutions by embracing outlaw innovators in the design of open data platforms is truly a complex undertaking whose success resides with a novel development approach that creates synergistic relationships between public and private interests.In particular, our research makes several contributions to the extant literature.First, it articulates three design principles from a successful implementation of an open data platform in a public institution that learned incrementally how to balance the public-private tension.Given that such platform approach to digital transformation in the public sector often falls short of its promises (Attard, Orlandi, Scerri, & Auer, 2015;Chen, Cao, & Liang, 2023;Gascó-Hernández, Martin, Reggi, Pyo, & Luna-Reyes, 2018) -i.e., improved governance transparency, enhanced public services, and increased civic engagement (Hein et al. 2023) -our design principles offer valuable insights to practitioners and researchers alike.These principles proved that embracing outlaw innovators into an ecosystem shaped by competing public and private concerns is both a realistic and worthwhile goal for public institutions.
At the same time, however, embracing the talents and labor of outlaw innovators will inevitably take considerable commitment on the part of the public institution itself to frame these external players as an integral part of its strategy to serve citizens, provide them with data access and a technical environment that caters to their heterogenous development needs, and treat them as design partners by ultimately relying on the same open data infrastructure that they are supposed to do.By doing this, public institutions create beneficial conditions for a successful application of our design principles, thus allowing themselves to achieve digital transformation via open data platforms surrounded by ecosystems of outlaw innovators and other developers (Hanelt et al., 2021) as well as to meet their fiduciary responsibilities toward the use of public funds.
For researchers, our three design principles provide insights into the digital transformation of public institutions driven by open D. Rudmark et al. data platforms.As called for by Bonina and Eaton (2020), our research brings new light on how to manage the complex challenges with governing open data in these institutions.Additionally, it provides insights into platform search theory by demonstrating that coherent and flexible searches need not be relegated to the platform ecosystem's periphery, as suggested by Brunswicker and Schecter (2019), but that they should become part of the platform core to better cater to the heterogeneous needs of external developers.Indeed, our first design principle highlights that process-oriented guidance is needed so that external designers can meet their design goals (Li et al., 2015;Markus et al., 2002;Walls et al., 1992;Walls, Widmeyer, & El Sawy, 2004).Another important contribution of our research is that it shows how IS researcher can make a difference in practice (Gregor & Hevner, 2013;Rosemann & Vessey, 2008;Wiener et al., 2018).In view of ADR as a research methodology (Sein et al., 2011), our study demonstrates the principle of guided emergence.This principle stipulates that an IT artifact is best understood from an ensemble view (Orlikowski & Iacono, 2001), reflecting structures from its surrounding ecology.While ADR problems stem from authentic organizational settings, early ADR stages are somehow institutionally decoupled to accommodate exploratory design.Over the course of the overall cycles, they then require the gradual molding of the artifact back into the institutional context to resolve the original problem and allow for ensemble artifact theorizing.
Manifesting the principle of guided emergence, this process balances conscious design choices and increasingly authentic structures and thus elevates both knowledge development and problem-solving.However, the current literature does not offer researchers sufficient guidance to navigate this transition.We suggest that the alpha version typically exists in a temporary organizational structure (e.g., workshops).Therefore, achieving structural influx becomes critical because of the limited organizational setting in which it is evaluated.The ADR team must find ways to mindfully design the alpha environment so that it allows for the problem's cardinal structural contours to determine the fitness of the proposed artifact.In this research, we included both outlaw innovators and organizational decision-makers in a workshop to simulate the necessary authenticity.The beta version, instead, closely mirrors realworld use, offering richer opportunities for ensemble artifact theorization.Here, ADR teams are advised to focus on the boundaries of ensemble authenticity.
To examine whether external developers appropriated our platform's resources, we publicly launched new APIs into the Trafiklab infrastructure with a time constraint, thus encouraging developers to invest the same effort and commitment as they would for a longterm project, but without committing to these design rules.For the release version, ADR teams must be able to mutate the materialization of the design knowledge to take the realities that shape operational systems into account.However, transitioning from beta to the release version in this ADR study necessitated a significant architectural change in that STA required a single interface in their system instead of separate interfaces for coherent and flexible searches.To ensure that the knowledge gained on coherent searches from the alpha and beta stages was not lost, the common use cases were published as example code in the release version.This change marked an essential material shift from the fixed endpoints of the beta version, albeit within the boundaries of the developed design knowledge.What APIs have you used?
• (how did you make the selection?) Simple and inviting registration and access • (Dedicated server environment)

••
How did you experience the process of accessing the API ("time-to-first-request")? o (Long / short, smooth / frustrating, simple / cumbersome) • Do you have any idea about what's in the user agreement?o (If so, what did you think of it?)• Which possible improvements could be made to access the API? Understand content, possibilities, and limitations • For the API(s) you used, how did you go about understanding what data was available and what could be done?o (Documentation, code sample, sample response, API console) • What is your experience of understanding what the API contains, what can and cannot be done with the API? o (smooth / frustrating, simple / cumbersome, inspiring / disappointing) • How did your assessment of the content of the API affect your work with the service?o (Did not affect, had to change (what?), Did not want to continue) • Which improvements could be made to better understand the API's content, capabilities and limitations?Working with the API • Can you describe for which environment the service was developed?o (This may have been described in the previous question about the service) o (Development environment / language, user platform, integrated services (e.g., map services)) • Given the environment, and the service you wanted to develop, how did you experience the API? o (Did anything change in the service?What in that case?• What is your overall experience of working with the API?Production set-up • Do you think the service will go into production?o (When in that case?) • If so, would you need to make any changes to your service (regarding the API)?o (Own server environment) o (More calls at trafiklab.se)Howdo you experience the work that must be done to take a job in production?• (Point out that this applies to work that is linked to the API) • (The process of getting more calls) • (Lack of written agreements − good or bad) Scraping In the past, the services developed have been based on scraped data.Would that be an option for you?o (Why / why not?) o (Describe the advantages / disadvantages of scraping / APIs) • If so, what, if anything, would need to be changed for you to use official APIs instead?Summary • What is your overall impression of the Swedish Transport Administration's APIs at Trafiklab?• Would you like to add anything else?Existing developers (Outlaw innovators) Background and service • Can you briefly describe your service and why you created it?• How do you retrieve data today?• How has this mechanism worked so far?o (Possible problems, more degrees of freedom) What APIs have you used?• (how did you make the selection?)• (how did you find out what APIs existed?) Get access How did you experience the process of accessing the API ("time-to-first-request")? o (Long / short, smooth / frustrating, simple / cumbersome) • Do you have any idea about the user agreement?o (If so, what did you think of it?)• How do you see the API being provided via the traffic lab? o (Together with other traffic APIs etc.?) • Which possible improvements could be made to access the API? Understand content, opportunities and limitations • For the API(s) you used, how did you go about understanding what data was available and what could be done?o (Documentation, code sample, sample response, API console) • What is your experience of understanding what the API contains, what can and cannot be done with the API? o (smooth / frustrating, simple / cumbersome, inspiring / disappointing) • How did your assessment of the API's content affect your work with your existing service?• (Matched in terms of content, not possible to move) • Which improvements could be made to better understand the API's content, capabilities and limitations?Working with the API • Can you describe for which environment the service was developed?o(This may have been described in the previous question about the service) o (Development environment / language, user platform, integrated services (e.g., map services)) • Given the environment, and the service you wanted to develop, how did you experience the API? o (Was there something in the service that was not compatible with the API?What in that case?• What is your overall experience of working with the API?Production set-up• Do you think you will move the service towards the official APIs? o (When in such case?) o (If not, why?What would need to change for this to happen?) • What do you need to do to take the service in production against the official API (regarding the API)?

Table 3
Apps with the highest number of downloads per smartphone platform.

Table 4
Empirical material related to the first ADR cycle.

Table 5
Empirical material related to the second ADR cycle.

Table 6
Empirical material related to the third ADR Cycle.

Table 7
Empirical material related to post-release trajectory.

Table 8
Number of new developer registrations, external API calls, internal API calls.

•
Background and third-party development -Describe your background and role at the Swedish Transport Administration?-How does the Swedish Transport Administration support external parties who want to develop innovative services on STA data?-What needs do you think these have?-How well are you familiar with what third-party developers exist?Are there others in the organization who are aware of this? -What does it mean that many third-party developers use unsanctioned data deliveries?-What does it mean that many travelers use services based on unofficial data deliveries?How would the Swedish Transport Administration's deliveries of traffic information for railways work and look like?-How does the Swedish Transport Administration view Open Data?The PSI Directive?In what way does the PSI directive affect the Swedish Transport Administration's information supply?• Check-out -How do you view the goal of this project?-In an ideal world, what would you like to achieve with the project?-How does it relate to organizational goals at the Swedish Transport Administration?-Contact again, for example on Skype?Long-term plan, maintenance − when and how did the service become more than a prototype?o How did the service spread and when?o What dialogue / contact / feedback do you have with end users of the service?• In such cases, how have your users expressed a need for information from the Swedish Transport Administration?• How did you communicate this to the Swedish Transport Administration?In what way did you experience the STA attitude towards this?o What contact have you had with the Swedish Transport Administration and the actors with data / information?• What do you think have been critical issues for the STA to release information to external actors?• Do you see a change in the response to these issues from the Swedish Transport Administration?• In what way has the STA attitude influenced your / your work and development of services?o What data source do you use today?• Technology o How does the service work?How do you retrieve information?o Changes in the course of development?o In an ideal world − how would information be delivered from the Swedish Transport Administration?What support or other help / support would you receive (or receive)?o Do you make money from the service?What does the business model look like?o The future of the service?Development ideas?Other projects / services?o What other services are on the market that we should contact D. Rudmark et al.

Evaluation interview protocol beta version
Below are questions to third-party developers.The text in parentheses are probes which are extra interesting and should be asked in a suitable context.New external developers Background and service • Tell me about the service you have developed o (Target group: yourself / others, etc.) o (why build the service: solve a problem, learning, mission, commercial service) o (What have you spent the most time on?)o (how do you develop: leisure, service: at home / at work) • Tell me about previous experience of development o (programming, APIs, mobile / web services) o (More projects?)o (In those projects, what do you work on the most?

Smartphone apps and their data sources App name Retrieved Platform Data source
Interview response since the data source was unable to determine from API request interception.