Study on Open Platforms

Online Appendix

The survey questionnaire and the aggregated survey results of the survey are available at the bottom of this page.

Open Software Platforms

Open software platforms form the basis for multiple systems in a particular domain (e.g., the Android platform for mobile devices, the Eclipse platform for IDEs) and are typically developed by a company or a consortium of companies (e.g., the Open Handset Alliance). To remain competitive or to survive in a market, many companies need to establish open software platforms suitable for outside contributions (e.g., apps, plug-ins) from external developers. Furthermore, with open platforms, companies can increase their innovation potential through additional developers, or address very specific requirements of individual customers.

Open platforms often arise from formerly closed software. For companies, the process of opening up software poses many technical, social, and organizational challenges. For instance, new APIs might need to be created and documented, or existing APIs have to be exposed to external developers. Companies also need to create awareness of the open platform, and potentially restructure development teams. While opening up a platform is a fairly common challenge, there are no best practices to guide this process. Specifically, companies need to find solutions for:

  • Estimating the effort and duration of the platform-opening process.
  • Determining the degree of platform openness (i.e., deciding which parts to expose).
  • Deciding which platform extension mechanism to use (e.g., APIs, plug-in mechanisms, web service frameworks) and assessing its effectiveness for allowing external contributions.
  • Assuring the quality of contributions and of the platform (e.g., stability, performance, security).
  • Handling the long-term platform evolution and assuring compatibility of contributions with the platform.

Study Goal

To elicit empirical data on the development of open platforms and to establish guidelines2 for the opening process, we conduct a study on industrial software platforms and the process of opening-up existing software to allow outside contributions. We strive to understand the process and the technical solutions applied, the organizational context, and the consequences of the technical solutions on long-term evolution and success of a platform.

Survey

Our first step is a survey to obtain preliminary insights into current practices. To this end, we are seeking participants who:

  • have experience with developing open platforms in an industrial context;
  • have opened an existing software to outside contributions; or
  • are currently in the process of opening-up software for outside contributions.

Participating in the survey allows participants to:

  • compare own practices with those of other companies;
  • distinguish good and bad development practices for open platforms;
  • receive a state-of-practice describing how companies open-up platforms.
  • Obtain knowledge about sustaining the long-term evolution of open platforms.

State of Research

Researchers commonly distinguish Software Product Lines (SPLs) and Software Ecosystems (SECOs). Both are approaches to software reuse in the large. By establishing a software platform, many different products (sharing common and variable functionality) can be derived. The core concept is variability, which may manifest in different forms, such as optional modules, parameters with different values, or the binding to different platforms. Individual products of the software family may be configured by selecting specific variable parts. In SPLs, the platform is predominantly closed, with companies carefully adding new functionality (a.k.a., "variability management"). In contrast, SECOs are based on open platforms, allowing contributions from external suppliers ("variability encouragement").

In SPLs, the selection of variabilities as part of the product configuration may principally be performed by end-users/customers. However, the creation of new variabilities is exclusively performed by the SPL owner. Similar to SPLs, SECOs allow configuration of individual products by selection from the variabilities. However, in contrast to SPLs, SECOs explicitly allow and foster the development of new variabilities through end-users/customers. This allows new directions of development, but reduces control over the development direction for the owner of the software family. SPLs and SECOs are not completely distinct approaches to managing software families: The literature describes the process of moving from an SPL to a SECO as quite common. However, empirical data regarding the changes required to the software undergoing this process is lacking. By conducting the study, we intend to remedy this problem by collecting empirical data from experiences in “opening up” an SPL to a SECO in an industrial context. As a result, we will gather information regarding how to adopt and sustain a Software Ecosystem (SECO) from a Software Product Line (SPL).

Team Members

 

Related Former Publications

This work follows-up on our previous studies of variability modeling, particularly in the systems software domain. Specifically:

 

AttachmentSize
Survey Questionnaire150.95 KB
Survey Results185.51 KB