Abstract
In the context of platforms, an open architecture is instrumental in enabling innovation by complementors. But as complementors increasingly deplete the innovation opportunities that the platform architecture affords, the platform architecture must evolve to reinvigorate the platform’s generative capacity. This article underscores the role of complementors in the process of platform architecture evolution by introducing the notion of architectural generativity. Architectural generativity involves actively soliciting and selectively incorporating contributions from complementors to help evolve the platform in unforeseen ways. In the case of the Mozilla Firefox web browser platform, complementors contributed new ways to facilitate access to the platform’s technological components and suggested better ways to control the platform and its architecture.
Platform orchestrators shape the generative capacity of their platform by selectively opening the platform architecture. 9 The platform architecture describes the internal structure of the platform, consisting of technological components that provide the platform’s data and functionality. 10 Platform orchestrators open up the platform architecture by pairing specific technological components with outward-facing interfaces, 11 such as application programming interfaces (APIs). 12 Those interfaces provide complementors with standardized access to platform data and functionality to leverage in developing their complementary innovations. 13 In this sense, innovation by complementors is inherently combinatorial 14 in that complementors often produce innovations simply by recombining the platform’s components in new and unanticipated ways.
But opening the platform architecture will not enable innovation ad infinitum. As consumer needs evolve over time 15 and complementors increasingly deplete the combinatorial options that the platform architecture affords, 16 the platform architecture will gradually become less conducive to innovation and must evolve to renew its generative capacity. Complementors are the main users of the platform architecture and are at the frontier of addressing emerging consumer needs. As such, they can provide valuable input based on their own experiences. 17 By actively soliciting and selectively incorporating complementors’ contributions, the platform orchestrator can evolve the platform architecture in ways it had not considered before, emphasizing that complementors’ contributions and the resulting changes to the platform architecture are unprompted and unanticipated. In this way architectural generativity contributes to the renewal of the platform’s generative capacity.
In Mozilla’s Firefox web browser platform, we found that complementors’ contributions came to account for over 40% of all the architectural changes we observed. Complementors make facilitating contributions in that they seek to enhance access to platform technological components. Complementors also advance controlling contributions, as they propose steps toward a platform architecture that is transparent, secure, and accessible for all, even if this sometimes goes counter to their own individual interests. Altogether, complementors’ contributions help optimize access to and the security of the platform architecture, ultimately enabling complementors to respond better to emerging consumer needs. Based on our analysis, we also provide several guidelines for platform orchestrators concerning the process of soliciting and incorporating complementors’ contributions to the platform architecture. We suggest using a structured approach to soliciting complementor contributions, navigating complementors’ conflicting interests, and explicitly considering potential interdependencies in the platform architecture
The Platform Architecture as an Enabler and Inhibitor of Open Innovation
Opening the Platform Architecture
A prerequisite to enabling complementors to innovate upon a platform is opening (parts of) the platform architecture. Here, openness refers to the extent to which the platform architecture grants complementors access to platform data and functionality. 18 At the extreme, a completely open platform puts no restrictions on access to platform data and functionality, allowing complementors to leverage the platform architecture as they see fit. 19 Choosing the optimal level of openness is a critical concern for platform orchestrators. 20 It entails a trade-off between unrestricted innovation, growth, and value creation on the one hand and control and value capture on the other. 21
The platform architecture provides a blueprint of how the platform provides its functionality. 22 Most platform architectures resemble modular structures, consisting of interdependent technological components that provide specific platform data and functionality. 23 Depending on the platform, those components could be pieces of hardware, source code libraries, data elements, or application functionality. To make specific technological components accessible to the outside world, including complementors, platform orchestrators use interfaces. 24 Interfaces, such as APIs and software development kits (SDKs), standardize interactions and encapsulate protocols for gatekeeping. 25 As such, interfaces provide platform orchestrators with means for opening their platform while retaining control over who can access platform data and functionality and how. 26 In fact, interfaces have numerous endpoints that prespecify use cases for the associated technological component, such that platform orchestrators can put explicit bounds on appropriate courses of action. From the complementors’ perspective, the availability of interfaces tells complementors what technological components they can leverage, while interface endpoints constitute the specific vocabulary of data and functionalities that complementors can implement in their complementary innovations. Figure 1 visualizes the platform architecture consisting of technological components, interfaces, and interface endpoints, as well as how those are leveraged in complementary innovations.
The Components of a Platform Architecture and How They Are Leveraged in Complementary Innovations.
For example, when developing a mobile Android app, developers can use more than 5,000 endpoints, corresponding to one of Android’s 236 interfaces. Most interfaces grant access to a specific component of a mobile device, such as Bluetooth, camera, or GPS. The Bluetooth interface, for instance, has endpoints to retrieve data on connected and disconnected Bluetooth devices and to search for and connect to nearby Bluetooth devices. Meanwhile, some device components may not be tied to an interface, such that they cannot be accessed by developers. For example, when Google Assistant first became part of Android, its voice-based assistance services were not accessible to developers. Only later, when performance had stabilized, the Google Assistant interface was introduced.
Developers build apps by interacting with various endpoints from different interfaces. A developer of a health-tracking application could use Bluetooth interface endpoints to connect to an external hearth rate monitoring device, endpoints from the mobile sensor interface to activate a phone’s movements sensor to count steps, and a location interface endpoint to access a mobile device’s GPS to track walking distance and speed. Each interface comes with documentation prescribing how developers can use the interface and its endpoints, what data and functionality they can and cannot access, and how frequently they can make use of the interface, among others.
Platform Architecture and Generative Capacity
The development of complementary innovations in the context of platforms is largely a combinatorial process. Combinatorial innovation refers to the reusing and mixing of existing knowledge and technologies in innovations. 27 As the number of available interfaces and endpoints for reuse and mixing increases, so does the volume and variety of conceivable innovations. Correspondingly, complementors’ innovative capacity is directly constrained by the openness of the platform architecture.
Put differently, the design of the platform architecture, as stipulated by the platform orchestrator, 28 is directly conducive to a platform’s generative capacity. Here, generativity refers to the platform’s overall ability to produce unprompted change driven by a large, varied, and uncoordinated crowd. 29 Generativity manifests itself both in the volume and variety of produced complementary innovations as well as in how the platform is viewed and interpreted. 30 As novel complementary innovations are introduced, the platform ends up catering to initially unforeseen use cases. Consequently, the meaning and value proposition of the platform is continually reinterpreted, expanded, and refined as complementors introduce ever-new combinations of platform data and functionality. 31
Evolution of the Platform Architecture
While most literature has focused on the initial designing of open platform architectures for generativity, 32 platform architecture is by no means static. 33 As the requirements of consumers are ever-changing, 34 the platform and its architecture need to evolve accordingly. For instance, in response to growing demand for image enhancements, commonly applied in mobile apps that use camera filters, the Android CameraX interface was introduced to allow performing the image analysis necessary for image modifications. Moreover, as large numbers of complementors keep combining platform data and functionality in novel ways, they are bound to at some point reach the boundaries of the innovation potential afforded by the platform architecture.
It is especially in this process of platform architecture evolution that complementors’ contributions are seemingly of value. 35 Complementors are the main users of the platform architecture and therefore well placed to quickly signal issues as they arise in use. More importantly, complementors are the ones most directly responding to the changing needs of platform consumers through their complementary innovations. 36 Hence, they are well-positioned to signal if, when, and whether the platform architecture must be adapted to accommodate emerging use cases and, if so, in what way. Their contributions are also likely different from the ones that the platform orchestrator could implement by itself. Indeed, the open innovation literature has long recognized the distinct value of inputs from those using an artifact as opposed to those designing it. 37 How exactly complementors contribute to the platform architecture we examine in the context of Mozilla’s Firefox web browser platform.
Method
We focused on the Mozilla Firefox web browser platform as an exemplary case. Firefox, a common research setting in the management literature, 38 is a popular web browser with over 250 million active users, corresponding to around ten percent of the total desktop web browser usage worldwide. 39 We focused on Firefox for its open source nature, 40 which meant we could observe how complementors seek to contribute to the platform architecture and what contributions were (not) incorporated into the platform architecture. For this, we made use of Bugzilla, Firefox’s development platform and forum, where Mozilla representatives and complementors interact about platform development. Importantly, Bugzilla also tracks all updates to Firefox’s source code, including new code commits, bug fixes, and patches, allowing us to observe, in detail, all changes that were made to the platform architecture and how complementors contributed to this.
Firefox is complemented by around 10,000 extensions, including advertisement blockers, password managers, and grammar and spell checkers. The extensions leverage Firefox’s interfaces and their endpoints to access specific data and functionality. Firefox has 44 interfaces with more than 600 interface endpoints. 41 The interfaces grant access to the user interface (e.g., sidebar, themes, windows), data elements (e.g., cookies, history, storage), and functionalities (e.g., notifications, search). Contained within a specific interface, each endpoint corresponds to a prespecified use case.
We focused our investigation on ten frequently used Firefox interfaces, roughly equally distributed across the different types of interfaces (i.e., user interface, data elements, and functionalities) and covering 194 interface endpoints: bookmarks, browserAction, downloads, history, menus, sessions, tabs, topSites, webNavigation, and webRequest. We treated each interface and its endpoints as an embedded unit within the larger Firefox platform architecture. 42 For each unit, we examined complementors’ contributions to the platform architecture, which entailed all kinds of proposals containing ideas, suggestions, and complaints. There is no set format in which proposals are made, but commonly they contain a description of the current behavior of the interface and the desired or proposed behavior, along with some additional argumentation.
We started our data collection when Firefox introduced a new interface standard, Web Extensions, because at this point it renewed the entire platform architecture. Our data collection stretched 18 major version releases, 43 corresponding with an observation window of more than two years. We accumulated a data set containing 374 archival documents, encompassing platform interface documentation, platform announcements, and complementor discussion threads from Bugzilla. Table 1 provides an overview of the data sources and how we used them in our analysis.
Overview of Data Sources.
Note: The main use case of each data source for the final analysis is given. When needed, data sources were used at a different stage of the analysis to get a more extensive overview of the case at hand. N indicates the number of documents collected.
Our data analysis proceeded in four stages. First, we constructed a timeline of interface (endpoint) changes to better understand how the platform architecture evolved. Second, we performed multiple rounds of open coding concerning complementors’ contributions to the platform architecture, mainly focusing on the discussions between Mozilla representatives and complementors, notably qualifying the type of the contributions. Third, we created sequences of interactions between Mozilla representatives and complementors to relate individual discussions back to specific elements of the platform architecture. Fourth, we used the grouped interaction sequences to identify how and when complementors contributed to the platform architecture.
During our analysis, we noticed instances where Firefox was particularly proficient in dealing with and incorporating complementors’ contributions, whereas in other instances it struggled. We explored whether this could in some way relate to how Firefox representatives managed this process. We made use of the constructed interaction sequences between Mozilla representatives and complementors and their connections to (un)realized changes in the platform architecture. Contrasting successful and unsuccessful sequences, three practices emerged that Firefox representatives engaged in when attempting to incorporate complementors’ contributions into the platform architecture.
Complementors’ Contributions to the Firefox Platform Architecture
Complementors’ Escalating Contributions to the Platform Architecture
Our observation period started when Mozilla released Firefox’s completely renewed platform architecture. The initial release, which essentially rebuilt Firefox’s platform architecture from the ground up, was the near-exclusive product of Mozilla’s own developers. The focus was on maximizing security and maintainability of the platform architecture. 44
Complementors’ initial responses were mixed. Some complementors considered the new developments “exciting.” Predominantly though, complementors raised numerous questions, from specific concerns regarding implementation (e.g., “what happens to add-on storage, e.g., localStorage, indexedDB, storage.local, [interfaces and interface endpoints]”) to more fundamental issues surrounding the development process of extensions: “hmm, this will make it very tedious to develop/test/debug add-ons that require any configuration—edit code, refresh, re-enter all config again, try, fail (with my luck), start over.” Strikingly, even though the initial platform architecture was developed internally by Mozilla, many concerns could not be readily mediated by platform representatives, as they were seemingly unanticipated. So, back then, platform representatives actively solicited the help of complementors, though without an explicit commitment to incorporate the resulting contributions: “if you make any explorations into that area, I’d be curious to know how it goes.”
As complementors gained more experience with the platform architecture, the nature of their input changed. Initially, complementors predominantly raised “what-if” or “could-be” questions: “is it possible in Webextensions [new interface standard] to block requests based on their content?” or “could you clarify: [how to request a permission].” But, with experience, complementors became more constructive, focusing on how the platform architecture could be improved. For example, one complementor posted the following: Any plans for runtime permissions instead of the “accept all or don’t install” approach? With that I mean permission controls similar to iOS and Android (6.0+), where apps request permissions on demand instead of all at once at install time. With the current approach, developers tend to request more permissions than necessary (or simply all of them) to avoid the permission update warning dialog.
As the quote illustrates, complementors’ contributions clearly go beyond general inquiries; their contributions are directly informed by their (unmet) architectural needs. In this instance, the complementor asked to make it possible to request optional permissions only when they are required, instead of upfront when the extension is installed, requesting permissions at the moment at which they are needed.
Over time, Mozilla started recognizing and appreciating the experience of its complementors. It not only monitored, but also incorporated more of their contributions into the platform architecture. As stated by Mozilla in one of the official release notes: We continue to receive a lot of feedback from developers and, based on that feedback, work is progressing on new features for Firefox 59 and beyond. Expect to see the WebExtensions API improve and grow, particularly in regard to the organization and management of tabs, as well as the theming API. As always, thank you for using Firefox and helping ensure that individuals have the ability to shape the Internet and their own experiences on it.
Indeed, we observed a strong increase in complementors’ contributions and their incorporation into the platform architecture. We visualized this trend in Figure 2. It plots the relative distribution of internal (i.e., by Mozilla) against external (i.e., by complementors) architectural contributions. Within roughly a year, more than 40% of all architectural changes became attributable directly to complementors.
The Relative Contribution of Mozilla and Complementors to the Evolution of the Platform Architecture.
The Types of Contributions That Complementors Make to the Platform Architecture
We observed at least two distinct types of contributions that complementors make to the platform architecture. First, complementors make facilitating contributions aimed at enhancing or optimizing access to technological components. Second, complementors make controlling contributions directed toward improving the security and configurability of the platform and its architecture.
As mentioned, complementors’ facilitating contributions enhance access to the platform’s technological components to aid the development of extensions, their own as well those of others. As such, facilitating contributions are central to expanding the generative capacity that the platform architecture affords. Through the addition, expansion, or refinement of interfaces and/or interface endpoints in response to such contributions, Mozilla provides complementors additional opportunities to innovate.
Facilitating contributions typically result from complementors’ direct experiences working with the platform architecture. They run into problems, face limitations, or want more wiggle room, and then propose ways to ameliorate such issues. One such instance occurred when a complementor made a request to allow extensions to change the appearance of the user interface on a per-window basis rather than for the entire web browser at once: I want each window to have its own title, badge text, icon, background color, or popup. The methods to set a value currently only allow setting it as a default for all tabs in all windows, or override the default value in a specific tab.
The complementor intended to develop a tab counter extension, an application that replaces the icon of the extension within the web browser toolbar with a counter displaying the number of open tab pages in the window. However, as extensions were unable to change the appearance of the web browser on a per-window basis, this feature could not be implemented. In fact, platform representatives were reluctant to permit such a feature, as one representative responded: I did some playing around with the current API, and it seems like you can accomplish this without an update to the API [description of potential workaround]. Do you still think you need this in the API for your use case, or some other use cases you can come up with? I’m just not sure what this enables, and it seems like it only saves about 20 lines of code if we add it.
The former quote underscores the value of complementors’ facilitating contributions. It is impossible for platform representatives to foresee all potential use cases, which here would involve going beyond the complementor’s implementation of a tab counter. Hence, the platform representative suggested a minor workaround instead. To emphasize this discrepancy in perspectives of complementors and platform orchestrator further, the complementor responded by proposing examples where workarounds lead to unsatisfactory outcomes: [One tab counter extension] just uses a global browserAction [icon]. This ensures the counter will flow nicely, but it won’t work if you have multiple windows side by side. It also has some other minor problems, like not immediately updating the counter when closing a tab. [Another tab counter extension] uses tab-specific browserActions [icon]. When you open a new tab, the counter briefly disappears and displays “wait.” This is not tolerable. Using the approach described in comment 1 [workaround proposed by platform representative], I have managed to do something better, but I noticed it would be much better with my proposal.
The complementor also went out of her way to propose alternative use cases in which her contribution could be of value: I can perfectly imagine some kind of a script or ad blocker that allows the user to specify different policies for each window and display the number of blocked items in that window. Alternatively, maybe some add-on wants tab-specific browserActions [icons] but wants them to persist when an existing tab navigates to a new page.
This response further underscores the value of facilitating contributions by complementors and how they might differ from the facilitating changes to the platform architecture that Mozilla can make by itself. Indeed, platform representatives were ultimately convinced of the utility of the complementor’s contribution and incorporated it into the platform architecture.
Complementors also make controlling contributions that seek to ensure a more transparent, secure, and configurable environment for all platform stakeholders (i.e., complementors, users, and the platform orchestrator). Controlling suggestions broadly relate to issues of platform gatekeeping, user security and control, and transparency. Complementors leverage Firefox’s platform architecture to develop extensions, but they must adhere to certain restrictions set by Mozilla. Not surprisingly, some of the complementors’ controlling contributions were concerned with alleviating some of those restrictions. One such example is a 150-character text selection limit, where “a [text] selection longer than 150 characters will result in cropping.” In other words, when users select a text section, extensions will only be able to retrieve the first 150 characters. This limitation was initially implemented to increase extension performance, improving Firefox’s responsiveness: “the 150 char limit was originally added in bug 221361 to deal with performance issues.” But as mentioned by one of the platform representatives, the core issue addressed dated back many years and was seemingly no longer of concern: “I have just noticed . . . bug 221361 [the 150-character restriction] relates to 14 years ago O_O. They were talking about low-spec computers.” In response to a complementor’s contribution, the character limit was eventually revoked.
Interestingly, some of the controlling contributions by complementors were actually directed at strengthening or expanding, rather than weakening, security measures. This suggests that complementors are not always exclusively concerned with their own innovation opportunities, instead adopting a broader lens as they thought about the security of Firefox’s users. One such example surfaced immediately after implementing a new interface endpoint that allowed complementors to access certain menu items from a user’s web browser. As one complementor reflected, This can introduce UI spoofing problem [a security risk], so this feature should be allowed only with special permission like “uiAlias” [a permission that is granted by the user]. Then the user can know what the add-on actually does before he installs the add-on.
Table 2 provides further examples of facilitating and controlling contributions by complementors from our empirical context.
Examples of Facilitating and Controlling Contributions to the Platform Architecture by Complementors.
The Value of Complementors’ Contributions to the Platform Architecture
The preceding descriptions of the contributions that complementors made to the Firefox platform architecture helped make clear the advantages of soliciting and incorporating complementor contributions. Naturally, soliciting complementor contributions creates a greater sense of belonging for complementors, enticing them to stay committed to the platform. As complementors leverage the platform architecture to develop their complementary innovations, complementors depend on the platform for the existence of their innovation. 45 Hence, it becomes important to make a concerted effort to take away some of the hurdles that complementors experience.
Perhaps more importantly, though, is that complementors’ contributions to the platform architecture seem distinctly different from, and often complementary to, the ways in which platform orchestrators can evolve the platform architecture by themselves. Complementors’ contributions are inspired by their own experiences with the platform architecture, and because complementors are many and heterogeneous, 46 this will ultimately yield a wide variety of contributions. All this accumulated experience with the platform architecture is impossible for the platform orchestrator to realize or emulate by itself. Given the generative capacity of digital platforms, 47 it is simply unfeasible for platform orchestrators to foresee all potential use cases, to evaluate all possible usage scenarios, and to proactively accommodate all emerging consumer needs through the platform architecture. Hence, by actively soliciting and incorporating contributions by complementors, platform orchestrators can better respond to the evolving architectural needs of complementors. We refer to this as architectural generativity to emphasize that complementors’ contributions and the corresponding changes to the platform architecture are unprompted and unanticipated.
By actively pursuing architectural generativity, platform orchestrators can renew the generative capacity of their platform. As consumer needs evolve and complementors increasingly hit the boundaries of the combinatorial potential that the platform architecture affords, the platform architecture must at some point evolve to create new opportunities for innovation. Harnessing the architectural input from complementors, the platform orchestrator can evolve its platform architecture more efficiently, radically, and likely faster.
Complementors’ facilitating and controlling contributions enact architectural generativity in two distinct ways. First, part of complementors’ contributions is targeted at optimizing the existing opportunities that the platform architecture affords. This is especially true for controlling contributions. Through their contributions, complementors aim to enhance and fine-tune access to existing interfaces and/or endpoints, augmenting the innovation potential and security of the platform architecture. Second, complementors’ contributions, and facilitating contributions in particular, also propel the further advancement of the platform architecture, that way expanding the opportunities that the architecture affords. Complementors’ contributions help redefine, enhance, and secure the platform architecture by proposing new interfaces and/or endpoints and by radically reimagining existing ones. In Figure 3, we visualize how the platform architecture evolves through architectural generativity and how this helps renew the platform’s generative capacity.
How architectural generativity contributes to the evolution of the platform architecture and helps renew the platform’s generative capacity.
Managing the Incorporation of Complementor Contributions into the Platform Architecture
Successfully soliciting complementors’ contributions and incorporating them into the platform architecture is not without challenges. Complementors’ contributions to the platform architecture are inspired by the immediate issues that complementors experience in working with the platform architecture, making their contributions many, heterogeneous, and of differing quality. From the Firefox context, we observed instances in which Mozilla was highly proficient in leveraging complementor contributions to the platform architecture, whereas in other cases, it struggled. Based on those observations, we formulated some guidelines for managers when dealing with complementors’ contributions to the platform architecture.
Organize the Solicitation of Complementor Contributions
Soliciting contributions to the platform architecture from complementors requires setting up dedicated input mechanisms, such as community forums or feedback reporting tools. But, as complementors are many, involving them in the process of evolving the platform architecture will likely yield a large, heterogeneous volume of contributions. It thus becomes important to also draw up mechanisms to carefully filter, organize, categorize, and manage all contributions.
Based on our observations from the Firefox case, the advice is to take a structured approach to soliciting, archiving, and processing complementors’ contributions. This could, for instance, involve adopting a pre-defined input structure for contributions to help standardize complementor input. The discussion forums could also be partitioned based on specific types of input, such that complementors make distinct types of suggestions in different places. This separates interactions between platform representatives and complementors about issues of granting access to additional data and functionalities from flagging bug fixes and security issues, for example. Doing so could help avoid confusion and side-tracking of discussions but requires active moderation and facilitation by platform representatives. It could also be beneficial to formulate an internal rank-ordering of architectural priorities so that it is clear what contributions require the most attention at a given point in time.
An illustrative example of the (dis)advantages of (not) facilitating structured discussion comes from the heavily debated implementation of Firefox’s tab hide interface endpoint, which set out to grant extensions the ability to hide active tab pages from the user’s view. Complementors were quick to contribute, but the discussion became unfocused due to the wide variety of issues that were brought forward: At this point, we are running over 135 comments on the bug [tab hide interface endpoint discussion] and the ability to focus on the code [implementation] is actually being impaired.
To alleviate the issue, platform representatives drew up an input structure to channel complementors’ contributions. They structured the discussion along three separate topics: functionality, implementation, and security. This effectively channeled complementors’ contributions and aided in processing them. It also facilitated in prioritizing the different contributions. In this case, Mozilla prioritized resolving all security issues first before turning to other types of improvements to the platform architecture.
Manage Complementors’ Conflicting Interests
Complementors often differ tremendously in their commitment to the platform, development experience and preferences, focus, and others. In some cases, complementors also directly compete with one another on the platform as they develop similar products. Consequently, contributions by complementors may (in part) be motivated by their own interests and may therefore go counter to the interests of others. The platform orchestrator may thus be presented with directly conflicting contributions, which require attention from (and active negotiation by) platform representatives. Haphazardly implementing the contributions of some complementors but not others could lead to conflicts or perceptions of the platform orchestrator playing favorites.
In the Firefox context, we observed many cases where complementors’ conflicting contributions, and an inability of platform representatives to negotiate a satisfying resolution, led to frustrations among complementors. One such occurrence was the implementation of an endpoint allowing extensions to define where newly opened tabs will be located: “to the left of the current tab, to the right of the current tab, at the end of the tab strip.” This is more complex than it appears at first, because the platform representatives also had to negotiate the order in which the tabs would open. One complementor proposed the following: if I have tabs “[a] b c” where “[a]” is currently active, and I open in bg [in background by extension] tabs “1 2 3” in that order from that tab, I would get “[a] 1 2 3 b c.”
A second complementor instead got accustomed to them opening in the naïve order: “[a] 3 2 1 b c.” [. . .] Then I switch to 1, read it and close it. Closing a tab focuses the one to the left, so I get tab 2, which is also quite convenient.
Yet another related decision concerned the tab that should be opened when an active tab is closed; this can be either the tab before or after the closed tab, or the previously active tab. In theory, Firefox representatives could decide to implement all scenarios, but this would be complex, susceptible to malfunctions, difficult to maintain, and confusing for users. As noted by a lead Firefox developer, “that’s not because it would be technically unfeasible but because it would be too expensive to maintain such a large API.” The platform representatives were cautious about involving themselves in the discussion and did not select any of the proposed usage scenarios, which eventually led to the complete dismissal of the initial contribution.
Thank you for your input, Dão [platform representative], we will respect your decision to r- [negative review] this feature request. I have removed this API from the WebExtensions roadmap and will continue to monitor market channels to determine what APIs we can offer to Firefox developers in the future.
This decision led to an outburst of negative and sometimes abusive comments by complementors, who lashed out at the way the Firefox representatives managed the situation. Not long later, the platform representatives reconsidered. They implemented an interface update at the discretion of a single platform representative, who had supposedly considered the most potent use cases for all complementors. The platform could have benefited from engaging in a more transparent, open, and proactive discussion between platform representatives and complementors on the most potent and widely accepted implementation by complementors.
Consider Technological Interdependencies in the Platform Architecture
Complementors have first-hand experience working with the platform architecture. As such, complementors contribute a unique perspective concerning the platform architecture, making their contributions highly valuable. However, because complementors only work with select parts of the platform architecture, it is important to realize that they typically will not fully grasp the blueprint and complexity of the entire platform architecture. We observed that this is true even in an open source and transparent context like Firefox, where it is arguably easier to observe the inner workings of a platform. Complementors have limited insight into the platform architecture, including its different components and their interactions. Accordingly, complementors will likely not have considered the complexity of the platform architecture and its consequences in their contributions. In this way, well-intended contributions by complementors can lead to problems due to unforeseen interdependencies. It is up to the platform representatives to evaluate complementors’ contributions against the architectural blueprint of the platform.
An example from Firefox is a series of complementor-contributed adjustments to the default Firefox menus: “consider removing default context menu items in extension frames [sidebar or popup]” (bug 1367160), “add ability to provide custom HTML elements [extension provided icons] working as alias of existing Firefox UI items [menu items],” (bug 1280347), “restrict context menus from showing up in the sidebar” (bug 1416839). Mozilla haphazardly incorporated all three contributions, which due to unforeseen interdependencies, led to a series of subsequent interventions by the platform. This is illustrated in the following quote by a platform representative: In bug 167160, I introduced menus.overrideContext [interface endpoint] to allow extensions to replace menus in their extension documents. In bug 1280347, I extended the method to allow extensions to change the context type to tab/bookmark. In bug 1416839, I added a “viewTypes” parameter to allow extensions to restrict the menu items to a specific menu. When the menu of a document is overridden [changing default menu item] (bug 1280347), documentUrlPatterns [endpoint used to overwrite a menu item based on the page URL/content] does not behave in this way. I was hoping that viewTypes from bug 1416839 would be an acceptable alternative, but I realized that this is not sufficient. . . . So I will add a patch that extends the behavior of documentUrlPatterns [interface endpoint]. This API implementation brings the desired ability to restrict menus to existing documents, without backwards-compatibility issues.
The former illustrates the potential benefits of putting certain processes in place to systematically evaluate complementors’ contributions, gauging them against the architectural blueprint of the platform. Platform representatives could, for instance, employ the four-eyes principle, standardized evaluation criteria, or a pre-defined decision tree as a screening tool before making a decision on the incorporation of a contribution by a complementor into the platform architecture.
Discussion
An open platform architecture is an important enabler for open innovation around platforms. Opening the platform architecture is conducive to the platform’s generative capacity, yet the architecture also has to evolve over time to continue to provide new innovation opportunities for complementors. Based on this study of Mozilla’s Firefox web browser platform, we illuminated how complementors can help advance a platform architecture. They contribute new ways of facilitating access to the platform’s technological components and propose new approaches to control and secure the platform and its architecture. By incorporating the contributions of complementors, platform orchestrators can evolve the platform architecture in unforeseeable ways. We referred to this as architectural generativity. Beyond the immediate benefit of an improved platform architecture, actively pursuing architectural generativity helps renew the platform’s generative capacity. As several platform orchestrators (e.g., Apple, Salesforce) already have dedicated feedback structures in place to collect complementors’ input concerning the platform architecture, those findings help underscore the value of actively soliciting and incorporating complementors’ contributions through such channels.
There is growing research interest in digital technologies with generative capacity, such as platforms. 48 Prior research has focused on how generative capacity is nurtured, 49 what the consequences of ensuing generativity are, 50 and how generative technologies evolve. 51 We contribute by introducing architectural generativity. Whereas generativity typically refers to the capacity of an artifact to produce and exhibit unprompted change, 52 architectural generativity is concerned specifically with the unpredictable evolution of the platform architecture driven by the voluntary contributions of complementors. Architectural generativity prompts a new pathway through which generative technologies, in our case a platform, evolve. Complementors are instrumental to the evolutionary trajectory through their contributions to the platform architecture. Many diverse complementors contribute to advancing the platform architecture from their unique experiences and vantage points, and incorporating these contributions not only renews the platform’s generative capacity, but also leads to evolutionary paths that are near impossible to predict in advance.
Open platform architectures can pit complementors against the platform orchestrator, as complementors may contest and even exploit the outward-facing components of the architecture (i.e., the interfaces and their endpoints). 53 Complementors’ stance concerning the platform architecture can also be constructive. Interestingly, complementors not only provide facilitating contributions that aim to expand and optimize complementors’ access to the platform’s technological components, but they also make controlling contributions that aid in better securing the platform architecture, even if this may limit their own innovation opportunities. In this regard, especially controlling contributions are indicative of a joint responsibility for the platform architecture of both platform orchestrator and complementors.
In this sense, our study also spotlights the complexity of innovation processes around platforms. Platforms have been heralded as an open innovation approach whereby the platform orchestrator benefits from the innovation efforts of a crowd of complementors. 54 Our finding that complementors actively contribute to the platform architecture emphasizes that platform orchestrators in fact internalize external contributions and efforts by complementors in various ways. 55 Essentially, the evolution of the platform architecture is a co-creational effort by platform orchestrators and complementors. Correspondingly, platforms feature concurrent and persistent in- and outflows of innovation and knowledge and are therefore best viewed through the lens of coupled approaches to open innovation. 55
Footnotes
Declaration of Conflicting Interests
The author(s) declared no potential conflicts of interest with respect to the research, authorship, and/or publication of this article.
Funding
The author(s) received no financial support for the research, authorship, and/or publication of this article.
Author Biographies
Coen van der Geest is a PhD Candidate at the KIN Center for Digital Innovation, School of Business and Economics, Vrije Universiteit Amsterdam (email:
Joey van Angeren is an Assistant Professor at the KIN Center for Digital Innovation, School of Business and Economics, Vrije Universiteit Amsterdam (email: