While we presented the core research results of our dissertation in the last three chapters, the exploratory style of significant parts of this work provides a good basis for constructing a theory. But although we studied a well-defined, broad range of systems that span diverse domains and leverage different variability mechanisms, it would be inappropriate to claim statistically significant conclusions by generalizing our observations. Thus, we develop testable hypotheses that explain core observations we made in our research.
In the following, we first provide a high-level overview on the conceptual framework we iteratively developed during our qualitative analyses. We then expand on major observations and correlations, depict our hypotheses, and formulate interesting future research questions indicated by our data.
7.1.1. Conceptual Framework: Putting it All Together
During the whole course of our analysis of variability modeling languages, models, and ecosystems, we iteratively developed, refined, and instantiated our conceptual framework based on empirical data. It also faced intensive discussions with the co-authors of the corresponding publications, to reach consensus about the concepts. The framework covers both product lines and ecosystems, and relates technical variability modeling concepts to organizational structures. It needs to be extended, refined, or even refuted with follow-up research in further domains.
The qualitatively developed framework aims at two goals: i) introduce abstractions over the system-specific terms to enable comparison, and ii) provide units of analysis for the quantitative studies. It combines all identified concepts from Chapters 4, 5, and 6. Table 7.1 summarizes the technical concepts of variability, and references corresponding
7. Discussion and Outlook
sections and tables. Fig. 7.1 illustrates the high-level concepts of the framework, with a focus on the organizational structure, and actors participating in an ecosystem.
Recall that the focus of our work lies in the variability modeling languages and models study in Chapters 4 and 5. It provided the basis for our exploratory analysis of open platforms in Chapter 6, whose main benefit is to broaden our perspective on variability to open platforms and modern, dynamic variability mechanisms. Our discourse from closed to open platforms, and our investigation of organizational structures led to this high-level framework.
Main Platform Free Market
Feature Dependency Variability Model abstraction Unit Parameter Asset configures Asset Base Suppliers Developers Consumers End-Users Configurator derive reconfigure develop Instance Installer make decision make decision Tools Decisions Decision Lifecycle Ecosystem Variability Representation Legend: Concept Optional Concept Action Tool Actor Inheritance Relation Containment Relation Binary Relation Content Flow Action Invocation
Basic Unit Composite Unit Dependency Manifest
Figure 7.1.: Conceptual framework: overview of ecosystem organization and variability mechanisms
7.1. Towards a Theory
Table 7.1.: Conceptual framework: overview
category concepts reference
va ri abilit y rep resentation Specification
variability models language concepts
(feature-model-like) feature kinds, representation, Overview in Section 4.3 and
hierarchy, grouping, constraints,
and others
Table 4.1
language semantics Section 4.4.8 and Sec-
tion 4.5.8, introduction in Section 2.3.2
model concepts
feature themes Section 5.3.1, Table 5.2
hierarchy structures Section 5.4.1
model metrics Overview in Table 5.6; values
in Tables 5.3, 5.4, and 5.5
mapping feature-to-code mapping Sections 4.3.6, 4.4.6, 4.5.6;
static analysis of build code in Section 4.5.6.2
manifests metadata and dependency types Section 6.4.1.2, Table 6.3,
manifest dependency types in Table 6.4
Asset Base basic units, unit parameters, and
composite units
Section 6.4.1.1, Table 6.3
dep
endencies
Types direct and capability-based Metamodel in Section 6.5.1.2
and Fig. 6.1, Capabilities in Section 6.5.1.1
Structures distribution properties Section 6.5.2, Fig. 6.2
in variability models Section 5.5.2.2, Fig. 5.8,
Fig. 5.9
in ecosystems Section 6.5.2, Appendix B.5
realization and
p
ro
cess
Tools configurators and installers Section 4.6, Table 6.3
Asset composition encapsulation and interaction Sections 6.4.3, 6.4.4, and Ta-
ble 6.3
Decisions configuration process Section 4.6.1, overview in
Section 2.2.2
decision lifecycle and binding Section 6.4.2
ecosystem
Organization main platform and free market, de-
velopment and variability manage- ment
Section 6.3.1, Table 6.1
7. Discussion and Outlook
7.1.2. Phenomena, Hypotheses, and Research Questions
We now report our most interesting findings as phenomena (facts that hold about our subjects), hypotheses (proposed explanations), and interesting research directions (marked with a dashed underline) indicated by empirical data. We also discuss their impact on the research fields of SPLE and software ecosystems.
7.1.2.1. Applicability of Variability Models
As can be seen in Tables 6.1 and 6.3, the existence of a variability model correlates with a centralized variability management structure. In eCos and Linux, many developers can contribute code and changes to the variability model. However, a core team must watch the impact of changes:
Hypothesis 1 A centralized variability model is fragile and has to be managed centrally
by a small team.
However, the benefit of centralized variability models is that they enable fine-grained variability mechanisms and almost arbitrary cross-cutting contributions, since the vari- ability model abstracts over the implementation, leveraging a flexible feature-to-code mapping.
Furthermore, distributed variability management correlates with the existence of manifest files. However, the opposite direction does not hold. eCos manages variability centrally using a model that is distributed via eCos packages. But since eCos failed to create a vibrant free market with distributed management, there is so far no evidence that distributed variability management could work when variability is described in a distributed variability model, richer than simple manifest files.
Interestingly, the structures of development and variability management are indepen- dent. This phenomenon challenges assumptions in the literature [VGP08, vGPB10, Sch10] that only distributed variability management is suited for distributed (or composition- oriented) development. The Linux kernel follows a highly distributed development process while managing variability centrally upon the variability model.
7.1.2.2. Relationship Between Variability Models and Manifests
We found that a clear difference between manifests and variability models is that manifests are always fully distributed, created as individual units with bilateral relations to other manifests, and managed as individual units. In contrast, variability models—even if split over multiple files—are created around a central hierarchy, and used and evolved as a whole. Their languages are also richer.
Variability models appear to impact dependency structures. In closed platforms, the median of declared dependencies per feature is lower than per basic unit in the open platforms. This phenomenon is seen across the subject spectrum without Android, which does not declare dependencies.
7.1. Towards a Theory
Hypothesis 2 Centrally managed variability using variability models facilitates sparse
dependency structures.
Variability models let developers optimize and collapse implementation-level depen- dencies, while the coordination cost for these activities in a distributed setting may be too high. Still, there can be other reasons for the lower number of dependencies in the systems with variability models, so this controversial hypothesis requires confirmation.
7.1.2.3. Domain Impact
The facilities to declare constraints, and in effect dependencies, are more sophisticated and more expressive in the closed platforms with variability models. The reasons for this can be manifold, but this is likely related to the requirements of the systems domain:
Hypothesis 3 Dependency mechanisms in systems software are more expressive than in
end-user applications due to the need for low-level, fine-grained, and static configuration.
The community has neither refuted nor confirmed the following controversial phe- nomenon emerging from our data: variability models are well-suited for projects in highly technical domains. However, this can be expressed negatively: non-technical consumers are unable to deal with complex dependencies in large models, while sparse dependencies hardly need models to be handled.
We are, however, unaware of studies explaining this complexity by performing a systematic requirements analysis and linking the requirements to dependency facilities.
7.1.2.4. Dependencies
One of our most interesting findings are capability-based dependencies, which target
abstractions of functionalities—capabilities—instead of basic units or features directly1.
We are not aware of SPLE literature describing such dependencies, nor any academic language supporting them. Such dependencies are essential and used in all our subjects to varying extents, even if the language (Kconfig) has no explicit concept for capabilities. Their widespread use indicates two important requirements for open platforms: i) language support and ii) management of centralized stable vocabularies.
The ecosystems with open platforms are larger and grow faster, and have a significantly higher proportion of capability-based dependencies. Although there are many reasons for the growth, such as business context, the sheer manpower of a vibrant community, or the huge market demand (in particular for mobile phones), we hypothesize that:
Hypothesis 4 A high amount of capability-based dependencies positively influences
growth.
For significant impact, capabilities should not just be labels (Debian, Eclipse), but described in a rich DSL, similar to intent filters (see Appendix) in Android.
7. Discussion and Outlook
Finally, the proportion of features and basic units that have dependencies is surprisingly high in all our subjects. Although the numbers between closed and open platforms are hardly comparable, these measures determine the complexity that tools supporting variability, including configuration, derivation, and analysis tools must cope with.
7.1.2.5. Beyond Variability Modeling
Finally, we provide a brief discussion on observations beyond the focus of our dissertation. These are worth formulating, since they potentially affect variability modeling. The following hypothesis strives to explain the lightweight processes in open platforms, which contrast the thorough contribution filtering in closed platforms, in particular the Linux kernel.
Hypothesis 5 Closed platforms must compensate missing guarantees of encapsulation
and interface mechanisms with heavyweight processes and strict policies to assure quality.
Recall that variability management in closed platforms aims at taming variability, to avoid diversity that has no business advantage. This is achieved by mechanisms such as: variability modeling, scoping (controlling and restricting contributions), maintain- ing variability information (unit parameters, dependencies, versioning) of basic units. These mechanisms are rather heavyweight, require advanced technical skills, and hinder contributions.
Open platforms add variability mechanisms that are different from these practices: uniform distribution channels within a free market, packaging mechanisms, maintaining capabilities, providing a common capability vocabulary, runtime resolutions of dependen- cies, little restrictions to contributions, highly dynamic runtimes, and interface mechanism. These variability mechanisms aim at encouraging contributions, and in fact, appear in our fastest-growing ecosystems Eclipse and Android.
The accumulation of new mechanisms of very different nature in open platforms calls for recognition of a new discipline in variability research: Variability Encourage-
ment. Verifying its underlying activities—such as maintaining capability vocabularies
and controlling processes with little restrictions to contributions— and relating them to known software engineering practices is an interesting agenda for follow-up research.
Furthermore, although variability management is always decentralized in the free mar-
ket2, sub-groups might have emerged that coordinate variability management activities,
such as scoping for a range of basic units. Identifying such groups would be a next research step to foster understanding of organizational structures in software ecosystems.