VariantSync

Today’s software is often released in multiple variants to meet all customer requirements. Software product lines have the potential to decrease development costs and time-to-market, and have been actively researched for more than two decades. Nevertheless, practitioners frequently rely on ad-hoc reuse based on a principle which is known as clone-and-own, where new variants of a software family are created by copying and adapting an existing variant. However, if a critical number of variants is reached, their maintenance and evolution becomes impractical, if not impossible, and the migration to a product line is often infeasible. With the research conducted in VariantSync, we aim to enable a fundamentally new development approach which bridges the gap between clone-and-own and product lines, combining the minimal overhead of clone-and-own with the systematic handling of variability of software product lines in a highly flexible methodology. The key idea is to transparently integrate the central product-line concept of a feature with variant management facilities known from version control systems in order to automatically synchronize a set of evolving variants. Lifting the underlying techniques employed by version control systems to the abstraction level of features which are shared among variants is an open problem and the main research challenge addressed in VariantSync. We believe that our research results have the potential to effectively change the way how practitioners will develop multi-variant software systems for which it is hard to foresee which variants will be added or released in the future.

The state-of-practice in engineering multi-variant software systems often follows a common pattern: The development starts with a single variant, where the overhead of product lines does not pay off. Later, further variants are added by copying and adapting an existing variant, and all of these forked variants evolve in parallel; a principle which is generally known as clone-and-own. However, if a critical number of variants is reached, maintaining such a software family becomes impractical. Moreover, migration to a product line involves so much effort to recover commonalities and differences between variants that it does not pay off when adding just a single variant. As it is typically unknown which and how much variants are added or released in the future, further variants are developed by means of clone-and-own, thus migration to a product line becomes increasingly impractical and the maintenance costs explode.

With the proposed research project VariantSync, we aim to overcome this dilemma through a fundamentally new development approach which bridges the gap between clone-and-own and product lines. The goal is to get rid of the limitations of both approaches while preserving their advantages. Specifically, we want to combine and integrate the minimal overhead of clone-and-own with the systematic handling of variability of software product lines in a highly flexible methodology. Instead of forcing developers to employ a heavyweight software product-line process, we transparently support their on-going development with concepts and techniques from software product-line engineering and version control systems. In our envisioned method, software development is performed according to a session-oriented editing model where the technical features being touched during an editing session are made explicit by developers. This way, software artifacts of all variants shall be mapped to a common set of features with minimal input by developers. The gathered domain knowledge shall be exploited to support the synchronization of variants during evolution, i.e., improvements in one variant shall be propagated to all other variants sharing the affected features in a highly automated fashion. Finally, the domain knowledge shall also serve as a basis for automatically creating variants that implement a new feature combination.

Fig. 1 illustrates how VariantSync bridges the gap between clone-and-own and product lines w.r.t. three dimensions, emphasizing the flexibility as well as the novel characteristics of our proposed methodology. First, Fig. 1(a) focuses on the degree of completeness of feature mappings. Whereas each artifact of a product line is mapped to features (blue spot in the upperright), there is no such mapping for clone-and-own (red spot in the lower-left). With VariantSync (green area in-between), any percentage of both existing and newly developed artifacts may be mapped to features. Second, Fig. 1(b) shows the extent to which artifacts implementing the same feature are synchronized among the variants, and the delay of such a synchronization. As artifacts are reused across variants in product lines, all possible variants are instantly synchronized (blue spot in the lower-right). With clone-and-own, changes to artifacts in one variant are propagated to other dedicated variants on demand, typically leading to a very few variants being synchronized at a certain point of time (red area next to the y-axis). VariantSync (green area in-between) will enable the synchronization of changes into any subset of variants at any time. Finally, Fig. 1(c) addresses the organization of the development of a family of software variants. With product lines, release cycles of variants need to be identical and developers are responsible for features. In clone-and-own, release cycles of variants are often not aligned and developers are typically responsible for variants rather than features. VariantSync (green area in-between) enables arbitrary release cycles of individual variants and supports the concurrent development of both features and variants.

Research Vision — Our overall goal is to establish a new methodology for the development, maintenance, and evolution of multi-variant software systems. It combines the flexibility of clone-and-own with the systematic handling of variability of software product lines, while keeping the standard version space organization of parallel development branches to remain compatible with mainstream version control systems and to avoid organizational constraints induced by a centrally managed software platform. The key idea is to transparently integrate the central product-line concepts of features and configurations with variant management facilities known from version control systems to automatically synchronize a set of evolving variants and to generate new variants.

Approach — To gather basic domain knowledge on features and configurations, we rely on two reasonable assumptions which are justified within in the literature. First, we assume that developers agree on a common nomenclature for the domain (i.e., features) and, for a given variant, the respective developers know which subset of features is implemented by that variant, as assumed by others. The set of available features is typically specified by the product documentation, and can also be retrieved from other departments within an organization (e.g., the sales department knows about product features). Second, we assume that developers know which feature or feature interaction they are working on, as assumed by others. Kästner et al. argue that developers typically have this piece of domain knowledge, and expert interviews on industrial clone-and-own show that it is most pronounced during implementation.

Our development methodology follows a session-oriented editing model, in which features being touched during an editing session are made explicit by developers in terms of a propositional formula over features referred to as feature context of that editing session. This is illustrated in Fig. 2, using a snapshot of the development of a simple graph management software. The snapshot comprises four features and four variants implementing different configurations (top right). The historical evolution of these variants is shown by the revision graph in the upper left, annotated by the feature contexts which led to the repository revisions r₆, r₈, r₁₀ and r₁₂. Feature contexts and configurations can be used to identify the target variants which need to be synchronized in response to evolution steps. For example, no synchronization is needed in response to the evolution step leading to revision r₆, as it affects the feature OptimalC which is only comprised by the modified variant v₄. In contrast, the changes to the shared feature Graph in the evolution step leading to revision r₁₀ need to be propagated to all other variants. The change resulting in revision r₁₂ needs to be propagated to two variants, whereas the synchronization of variant v₁ cannot be performed automatically due to synchronization conflicts (red arrow). The feature context is not only used to determine target variants, but also to establish a mapping from features to artifacts in the currently edited variant as well as in other variants (bottom right). This feature mapping may also be employed to derive new variants and to reconfigure existing variants. For example, we may obtain a new variant comprising the features Directed and Weighted by starting from variant v₁ and transferring an implementation of feature Weighted from variant v₃ or v₄, or by starting from variant v₄ and deleting all parts related to feature OptimalConnection.