whether the Linux Kernel can be seen as a product line, concluding that it shares many characteristics with software product lines, such as configurability and code reuse. The connection between the Kconfig language (see Section 4.2.2) and feature modeling was made subsequently in [SSP08]. We advance this work by studying Kconfig’s semantics and the Linux model.
Tartler et al. [TLSSP11] apply SAT checks to #IFDEF conditions in Linux source code in order to identify dead code. Furthermore, the code cloning research commu- nity has extensively studied the Linux Kernel [RC07], for example to aid product line analysis [KS07].
Also eCos was studied before. A survey on configurable operating systems [FSH+01]
emphasizes eCos’ component-oriented architecture. Lohmann et al. [LST+06] quan-
titatively analyze aspects (cross-cutting concerns) in the eCos system and perform a feasibility study on the refactoring of these code parts into an aspect-oriented approach with AspectC++. Our work complements these studies and advertises eCos and its configurator infrastructure as highly interesting study objects for further research.
3.5. Knowledge-Based Configuration
Recognizing many overlaps between software configuration, and the older AI-related field of knowledge-based configuration, recent research has started to investigate their relationships, including work on leveraging product configurators and AI techniques for
software product lines [AMS04, HWK+06, ASM04]. Although the relationships between
software and product configuration are blurred and part of ongoing research, the following works are closely related to ours.
Hubaux et al. [HJD+12] present a research agenda on unifying software and product
configuration. Their comparison of both fields concludes that software configuration can benefit from existing techniques in product configuration, such as in the expressiveness of modeling languages and reasoning support (e.g. to optimize configurations according to certain criteria). Notably, they emphasize that both fields lack research on evolution of models.
Very recently, Abbasi et al. [AHA+12] empirically study 111 web configurators. Their
conceptual framework to classify the investigated cases comprises the visualization of the configuration options, the handling of constraints, and the type of configuration process supported. They develop a JavaScript-based tool infrastructure to semi-automatically extract datasets (e.g. configuration options and attributes) from the web-based configu- rators. Among others, the authors confirm that hierarchical organization and grouping of configuration options is commonly used. xor groups are the most frequent kind of grouping with constraints. Furthermore, cross-tree constraints exist. The authors also identify limitations in the reasoning procedures, with regard to reliability and runtime efficiency.
Rabiser et al. [RGL12] study user guidance support in product configurators. They identify seven core capabilities from the literature, implement these in the DOPLER tools suite (see Section 2.2), and evaluate each of which in a user study with industrial
3. State of Research
participants. Among others, capabilities such as visibility control (hide and show options), views and filters, or freedom in navigation are very important, while immediate feedback turns out to be hard to comprehend for users. Reset and undo functionality is essential to experiment with choices and their impact.
3.6. Software Ecosystems
General work on software ecosystems targets business, strategic, and organizational aspects [BWB12]. Barbosa et al. [BA11] review publications on software ecosystems using a systematic mapping study. They confirm that ecosystem are technical constructs, related to open source software and SPLE; however, none of their identified publications covers technical mechanisms to support variability.
Bosch [Bos09] presents a taxonomy of software ecosystems, applicable to all of our subjects. He takes the perspective of economical incentives of open platforms for software development. Main characteristics include value and attractiveness offered to existing and new users, collaborations with partners, and the practical scalability of ecosystems. Later, Bosch et al. [BBS10] study companies relying on software product lines and on software ecosystems, and the problems resulting from these approaches. The authors describe software ecosystems as the logical destiny of successful product lines. While both leverage a platform to build products, a major property of software ecosystems is that developers extending the platform can stem from other organizations.
Kabbedijk et al. [KJ11] study defining characteristics of open-source ecosystems using the Ruby ecosystem, which also relies on manifests to represent variability. They focus on the role of developers and basic units (gems). We study similar subjects, and our conceptual framework (summarized in Section 7.1.1) includes both of these concepts and.
Messerschmitt et al. [MS03] characterize software ecosystems according to their context, which, notably, also comprises technical aspects. They differentiate between organiza- tional, business, and technical aspects of software manufacturing; and identify stakeholders and their interests and views on software ecosystems. Our work complements theirs with an empirical study of existing software ecosystems.
Jansen et al. [JFB09] present a research agenda for software ecosystems. They propose to study ecosystems such as the MySQL/PHP, Microsoft Windows, and iPhone apps. We deliver on this agenda by investigating similar ecosystems. They announce the characterization and modeling of software ecosystems as a main challenge—which we address with our conceptual framework in Section 6.2 and Section 7.1.1.
3.6.1. Development Processes
Development processes in software ecosystems are studied by van Gurp et al. [vGPB10], who analyze the Eclipse and Debian ecosystems. They show that indeed large-scale open software development can be performed successfully using practices not seen in SPLE. Furthermore, they conclude that in open compositional development, requirements of components are often developed independently by separate teams, which leads to