pith. machine review for the scientific record. sign in

arxiv: 2604.15957 · v1 · submitted 2026-04-17 · 💻 cs.SE

Recognition: unknown

Small Yet Configurable: Unveiling Null Variability in Software

Xhevahire T\"ernava , Georges Aaron Randrianaina , Luc Lesoil , Mathieu Acher
Authors on Pith no claims yet

Pith reviewed 2026-05-10 09:11 UTC · model grok-4.3

classification 💻 cs.SE
keywords small-scale softwareconfigurabilitynull-variable systemsGNU coreutilscompile-time variabilityrun-time variabilitysoftware evolutioncodebase size
0
0 comments X

The pith

Even small programs can have up to 76 compile-time and run-time configuration options, with variability increasing over releases.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper measures configurability across 108 programs from the GNU coreutils collection and finds that even these small-scale systems display substantial variability, reaching a maximum of 76 options in a single program. It identifies a 0.78 correlation between run-time variability and codebase size, and tracks 20 of the smallest programs across 85 releases to show that the total number of options tends to grow, driven mostly by new compile-time features. The authors introduce the notion of a null-variable software system, defined as one whose configurability extends no further than its mandatory features. These results indicate that high configurability is not restricted to large systems and that deliberate choices about where and when to expose options can limit growth in code size and complexity.

Core claim

By examining 108 programs from GNU coreutils, the study reveals that even small-scale software can possess significant configurability, with programs offering as many as 76 options at compile-time and run-time. Analysis of historical releases shows that this variability tends to accumulate, mainly through additional compile-time options. The authors define a null-variable software system as one that provides no configurability beyond its mandatory features, positioning such systems as targets for lightweight and maintainable development.

What carries the argument

The null-variable software system, a program whose configurability is restricted to mandatory features only, used as a baseline to contrast with systems that accumulate optional compile-time and run-time options.

If this is right

  • High configurability is not exclusive to large-scale systems.
  • Variability tends to increase over time, primarily due to the added compile-time variability.
  • Shifting options between run-time and compile-time, removing unnecessary run-time variability, or resolving compile-time variability early can help reduce codebase complexity and size.
  • Reducing unnecessary variability can lead to lightweight, smaller, and more maintainable software.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • Designers of new small utilities could target null-variable status to keep binaries and codebases minimal from the start.
  • The observed correlation between size and run-time options suggests that growth in one tends to drive growth in the other across software evolution.
  • The distinction between compile-time and run-time options offers a concrete lever for controlling long-term complexity in any configurable system.

Load-bearing premise

The 108 GNU coreutils programs are representative of small-scale software systems in general and that the counting of compile-time versus run-time options accurately captures configurability without systematic under- or over-counting.

What would settle it

A measurement showing that most other collections of small programs average fewer than ten configuration options each, or that the 20 smallest coreutils programs exhibit no net increase in options across their release history.

Figures

Figures reproduced from arXiv: 2604.15957 by Georges Aaron Randrianaina, Luc Lesoil, Mathieu Acher, Xhevahire T\"ernava.

Figure 1
Figure 1. Figure 1: Dependency graph between programs and .c files to concatenates and writes files; echo, which prints a line of text; ls, which lists directory contents; and mkdir, which makes direc￾tories. Their historical relevance makes coreutils a cornerstone of GNU/Linux systems, representative of traditional UNIX-like util￾ities. The main reasons why we chose to analyze them are the fact that they are quite well-known… view at source ↗
Figure 2
Figure 2. Figure 2: The variability, binary size, LoC and usage of 108 programs, as subjects, from the GNU [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: Changes in LoC over time for the 20 smallest programs, from 2003 (v 4.5.1) to 2022 (v 9.1) [PITH_FULL_IMAGE:figures/full_fig_p006_3.png] view at source ↗
read the original abstract

Many small-scale software systems, that is, with limited codebase or binary size, are widely used in everyday tasks, yet their configurability remains largely unexplored. At the same time, studies on modern software systems show a trend toward increasing configurability, alongside growing interest in building immutable, specialized, and reproducible software. In this paper, we present the first empirical study on the extent of configurability in small-scale software systems. By analyzing 108 programs from GNU coreutils, we show that even small programs can exhibit significant compile-time and run-time variability, with up to 76 options per program. Then, there is a high correlation (0.78) between run-time variability and codebase size. Furthermore, an analysis of the 20 smallest programs across 85 releases reveals that variability tends to increase over time, primarily due to the added compile-time variability. This suggests that shifting options between run-time and compile-time, removing unnecessary run-time variability, or resolving compile-time variability early, can help reduce codebase complexity and size. We also introduce, for the first time, the concept of null-variable software system, one with no configurability beyond mandatory features. Our findings show that high configurability is not exclusive to large-scale systems and that reducing unnecessary variability can lead to lightweight, smaller, and more maintainable software. We hope this effort contributes to designing new software by understanding how to balance its configurability with codebase size.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

3 major / 2 minor

Summary. The paper presents the first empirical study of configurability in small-scale software by analyzing 108 GNU coreutils programs. It reports that even small programs exhibit substantial variability, with up to 76 options per program, a correlation of 0.78 between run-time variability and codebase size, and increasing variability over time (primarily compile-time) in the 20 smallest programs across 85 releases. The authors introduce the concept of null-variable software systems (no configurability beyond mandatory features) and argue that reducing unnecessary variability can yield smaller, more maintainable software.

Significance. If the measurements hold, the work is significant for providing the first quantitative data on configurability in small programs, countering the assumption that high variability is exclusive to large systems. The size correlation and temporal trends supply concrete, actionable observations for designing lightweight and reproducible software. The introduction of null-variable systems is a novel conceptual contribution, and the use of real open-source code with historical releases strengthens the empirical basis.

major comments (3)
  1. [Methodology section] The methodology for extracting, counting, and classifying compile-time options (e.g., from configure/autotools/#ifdef) versus run-time options (command-line flags) is not described, including handling of option dependencies or validation against source code. This is load-bearing for the central claims, as the reported maximum of 76 options, the 0.78 correlation, and the time-series increase all rest on the accuracy of this classification (see Abstract and the empirical study description).
  2. [Program selection / data collection] The selection of the 108 GNU coreutils programs as representative of small-scale software systems lacks explicit criteria, justification, or comparison to other small programs. This undermines generalizability of the variability findings and the claim that high configurability is not exclusive to large-scale systems.
  3. [Longitudinal analysis] The longitudinal analysis (20 smallest programs, 85 releases) inherits the same unvalidated option-counting procedure, so the conclusion that variability increases primarily due to added compile-time options cannot be assessed for robustness against confounding factors such as release age or feature type.
minor comments (2)
  1. [Abstract] The abstract introduces the term 'null-variable software system' without a concise definition; adding one sentence would improve readability.
  2. [Results section] Tables or figures reporting option counts, the correlation, or release trends would benefit from explicit captions detailing the exact counting rules applied.

Simulated Author's Rebuttal

3 responses · 0 unresolved

We thank the referee for their detailed and constructive feedback on our manuscript. We have carefully considered each major comment and revised the paper to address the concerns raised, particularly by enhancing the methodology description and providing more justification for our choices. Below, we provide point-by-point responses.

read point-by-point responses

  1. Referee: [Methodology section] The methodology for extracting, counting, and classifying compile-time options (e.g., from configure/autotools/#ifdef) versus run-time options (command-line flags) is not described, including handling of option dependencies or validation against source code. This is load-bearing for the central claims, as the reported maximum of 76 options, the 0.78 correlation, and the time-series increase all rest on the accuracy of this classification (see Abstract and the empirical study description).

    Authors: We agree that the original manuscript lacked a detailed description of the methodology for option extraction and classification. This was an oversight in our presentation. In the revised version, we have substantially expanded the 'Methodology' section to include: (1) a step-by-step description of how compile-time options were identified from configure scripts, Makefile.am, and preprocessor directives (#ifdef, #if); (2) how run-time options were extracted by parsing the getopt or similar flag-handling code in the source; (3) our decision to count distinct options without enumerating all dependency combinations, as the focus is on the presence of configurability rather than the full configuration space size; and (4) validation through manual cross-checking of counts for 10 randomly selected programs against their source code and documentation. We believe these additions make the measurements transparent and reproducible. revision: yes

  2. Referee: [Program selection / data collection] The selection of the 108 GNU coreutils programs as representative of small-scale software systems lacks explicit criteria, justification, or comparison to other small programs. This undermines generalizability of the variability findings and the claim that high configurability is not exclusive to large-scale systems.

    Authors: We selected the GNU coreutils because they form a standard set of small, widely-used utilities with publicly available source code and release history, allowing for both cross-sectional and longitudinal analysis. However, we acknowledge the need for explicit criteria. In the revision, we have added a new subsection 'Program Selection' that specifies our criteria: programs with source code size less than 50,000 LOC and binary size under 1MB (to focus on small-scale), all from the coreutils suite to ensure consistency in build system and domain. We also include a discussion of limitations, noting that while coreutils are representative of Unix command-line tools, results may not generalize to all small software (e.g., embedded systems or GUI apps), and we suggest future work on other corpora like BusyBox for comparison. revision: yes

  3. Referee: [Longitudinal analysis] The longitudinal analysis (20 smallest programs, 85 releases) inherits the same unvalidated option-counting procedure, so the conclusion that variability increases primarily due to added compile-time options cannot be assessed for robustness against confounding factors such as release age or feature type.

    Authors: The longitudinal analysis does rely on the same counting procedure, which we have now validated as described in response to the first comment. To address potential confounding factors, we have added in the revised manuscript: an analysis of variability trends normalized by release age (to check if older releases have less time to accumulate options), and a categorization of added options by type (e.g., new features vs. build options). While fully controlling for all feature types is beyond the scope, these additions provide evidence that the increase is not solely due to age or specific feature additions. We maintain that the primary driver is compile-time options, but have softened the language to 'primarily due to' based on the data. revision: partial

Circularity Check

0 steps flagged

No circularity: purely observational empirical measurements

full rationale

The paper reports direct counts of compile-time and run-time options across 108 GNU coreutils programs, a correlation coefficient computed from those counts, and a time-series trend observed in 20 programs over 85 releases. No equations, fitted parameters, predictions, or derivations appear; the central claims are literal summaries of the extracted data. No self-citations are invoked to justify uniqueness or forbid alternatives, and the introduced term 'null-variable software system' is a straightforward definition rather than a result derived from prior claims. The study is therefore self-contained against external benchmarks with no reduction of outputs to inputs by construction.

Axiom & Free-Parameter Ledger

0 free parameters · 2 axioms · 1 invented entities

Claims rest on empirical counts from a specific corpus of open-source utilities plus standard assumptions about what constitutes compile-time versus run-time variability; no free parameters are reported.

axioms (2)
  • domain assumption GNU coreutils programs constitute a representative sample of small-scale software systems
    The entire analysis is built on these 108 programs and their 85-release history.
  • domain assumption Configurability can be reliably quantified by enumerating compile-time and run-time options
    Central measurement technique used to produce all reported numbers and the 0.78 correlation.
invented entities (1)
  • null-variable software system no independent evidence
    purpose: Label for systems possessing no configurability beyond mandatory features
    New definitional term introduced to highlight the opposite end of the variability spectrum.

pith-pipeline@v0.9.0 · 5564 in / 1330 out tokens · 35337 ms · 2026-05-10T09:11:08.331631+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

53 extracted references · 35 canonical work pages

  1. [1]

    Iago Abal, Claus Brabrand, and Andrzej Wasowski. 2014. 42 variability bugs in the Linux Kernel: A qualitative analysis(ASE ’14). Association for Computing Ma- chinery, New York, NY, USA, 421–432. https://doi.org/10.1145/2642937.2642990

    work page doi:10.1145/2642937.2642990 2014

  2. [2]

    Iago Abal, Jean Melo, Ştefan Stănciulescu, Claus Brabrand, Márcio Ribeiro, and Andrzej Wąsowski. 2018. Variability bugs in highly configurable systems: A qualitative analysis. 26, 3, Article 10 (jan 2018), 34 pages. https://doi.org/10. 1145/3149119

    2018

  3. [3]

    Mathieu Acher, Hugo Martin, Luc Lesoil, Arnaud Blouin, Jean-Marc Jézéquel, Djamel Eddine Khelladi, Olivier Barais, and Juliana Alves Pereira. 2022. Feature subset selection for learning huge configuration spaces: The case of Linux Kernel size. InProceedings of the 26th ACM International Systems and Software Product Line Conference - Volume A(Graz, Austria...

    work page doi:10.1145/3546932.3546997 2022

  4. [4]

    Mamdouh Alenezi and Khaled Almustafa. 2015. Empirical analysis of the com- plexity evolution in open-source software systems.International Journal of Hybrid Information Technology8, 2 (2015), 257–266

    2015

  5. [5]

    Mohannad Alhanahnah, Yazan Boshmaf, and Ashish Gehani. 2024. SoK: Software debloating landscape and future directions(FEAST ’24). Association for Com- puting Machinery, New York, NY, USA, 11–18. https://doi.org/10.1145/3689937. 3695792

    work page doi:10.1145/3689937 2024

  6. [6]

    2009.A Statistical Learning Perspective of Genetic Programming

    Sven Apel, Don Batory, Christian Kästner, and Gunter Saake. 2016.Feature- oriented software product lines. Springer. https://doi.org/10.1007/978-3-642- 37521-7

    work page doi:10.1007/978-3-642- 2016

  7. [7]

    Don Batory. 2005. Feature models, grammars, and propositional formulas. In Software Product Lines, Henk Obbink and Klaus Pohl (Eds.). Springer Berlin Heidelberg, Berlin, Heidelberg, 7–20

    2005

  8. [8]

    Brown, Adam Meily, Brian Fairservice, Akshay Sood, Jonathan Dorn, Eric Kilmer, and Ronald Eytchison

    Michael D. Brown, Adam Meily, Brian Fairservice, Akshay Sood, Jonathan Dorn, Eric Kilmer, and Ronald Eytchison. 2024. A broad comparative evaluation of software debloating tools. In33rd USENIX Security Symposium (USENIX Security 24). USENIX Association, Philadelphia, PA, 3927–3943. https://www.usenix.org/ conference/usenixsecurity24/presentation/brown

    2024

  9. [9]

    Carl Burch. 2012. Binding time. http://www.cburch.com/books/bind/. Accessed: 2025-04-24

    2012

  10. [10]

    Rafael Capilla, Jan Bosch, Kyo-Chul Kang, et al . 2013. Systems and software variability management.Concepts Tools and Experiences10 (2013), 2517766

    2013

  11. [11]

    Rafael Capilla, Barbara Gallina, Carlos Cetina, and John Favaro. 2019. Op- portunities for software reuse in an uncertain world: From past to emerg- ing trends.Journal of software: Evolution and process31, 8 (2019), e2217. https://doi.org/10.1002/smr.2217

    work page doi:10.1002/smr.2217 2019

  12. [12]

    Paul Clements. 2019. Managing variation: An industrial perspective on product line engineering. In2019 IEEE/ACM 41st International Conference on Software Engineering: Companion Proceedings (ICSE-Companion). IEEE, 1–1. https://doi. org/10.1109/ICSE-Companion.2019.00020

    work page doi:10.1109/icse-companion.2019.00020 2019

  13. [13]

    Krzysztof Czarnecki, Paul Grünbacher, Rick Rabiser, Klaus Schmid, and An- drzej Wąsowski. 2012. Cool features and tough decisions: A comparison of variability modeling approaches. InProceedings of the sixth international work- shop on variability modeling of software-intensive systems. 173–182. https: //doi.org/10.1145/2110147.2110167

    work page doi:10.1145/2110147.2110167 2012

  14. [14]

    Sascha El-Sharkawy, Nozomi Yamagishi-Eichler, and Klaus Schmid. 2019. Metrics for analyzing variability and its implementation in software product lines: A systematic literature review.Information and Software Technology106 (2019), 1–30. https://doi.org/10.1016/j.infsof.2018.08.015

    work page doi:10.1016/j.infsof.2018.08.015 2019

  15. [15]

    Paul Gazzillo and Myra B Cohen. 2022. Bringing together configuration research: Towards a common ground. (2022). https://doi.org/10.1145/3563835.3568737

    work page doi:10.1145/3563835.3568737 2022

  16. [16]

    GNU. [n. d.]. Autoconf - GNU Project. https://www.gnu.org/software/autoconf/

  17. [17]

    Axel Halin, Alexandre Nuttinck, Mathieu Acher, Xavier Devroey, Gilles Perrouin, and Benoit Baudry. 2019. Test them all, is it worth it? Assessing configuration sampling on the JHipster web development stack.Empirical Softw. Engg.24, 2 (apr 2019), 674–717. https://doi.org/10.1007/s10664-018-9635-4

    work page doi:10.1007/s10664-018-9635-4 2019

  18. [18]

    G. J. Holzmann. 2015. Code Inflation.IEEE Software32, 02 (2015), 10–13. https: //doi.org/10.1109/MS.2015.40

    work page doi:10.1109/ms.2015.40 2015

  19. [19]

    Lopez-Herrejon

    Seiede Reyhane Kamali, Shirin Kasaei, and Roberto E. Lopez-Herrejon. 2019. Answering the call of the wild? Thoughts on the elusive quest for ecological validity in variability modeling(SPLC ’19). Association for Computing Machinery, New York, NY, USA, 143–150. https://doi.org/10.1145/3307630.3342400

    work page doi:10.1145/3307630.3342400 2019

  20. [20]

    1990.Feature-oriented domain analysis (FODA) feasibility study

    Kyo C Kang, Sholom G Cohen, James A Hess, William E Novak, and A Spencer Pe- terson. 1990.Feature-oriented domain analysis (FODA) feasibility study. Technical Report. Carnegie-Mellon Univ Pittsburgh Pa Software Engineering Inst

    1990

  21. [21]

    Giarrusso, Tillmann Rendel, Sebastian Erdweg, Klaus Ostermann, and Thorsten Berger

    Christian Kästner, Paolo G. Giarrusso, Tillmann Rendel, Sebastian Erdweg, Klaus Ostermann, and Thorsten Berger. 2011. Variability-aware parsing in the presence of lexical macros and conditional compilation. 46, 10 (oct 2011), 805–824. https: //doi.org/10.1145/2076021.2048128

    work page doi:10.1145/2076021.2048128 2011

  22. [22]

    1948.Rank correlation methods

    Maurice George Kendall. 1948.Rank correlation methods. Harvard Book, Harvard

    1948

  23. [23]

    Michael Krisper and Christian Kreiner. 2016. Describing binding time in soft- ware design patterns. InProceedings of the 21st European Conference on Pattern Languages of Programs. 1–15. https://doi.org/10.1145/3011784.3011811

    work page doi:10.1145/3011784.3011811 2016

  24. [24]

    Jacob Krüger, Wanzi Gu, Hui Shen, Mukelabai Mukelabai, Regina Hebig, and Thorsten Berger. 2018. Towards a better understanding of software features and their characteristics: A case study of Marlin(V AMOS 2018). Association for Computing Machinery, New York, NY, USA, 105–112. https://doi.org/10.1145/ 3168365.3168371

    work page arXiv 2018

  25. [25]

    Elias Kuiter, Chico Sundermann, Thomas Thüm, Tobias Hess, Sebastian Krieter, and Gunter Saake. 2025. How configurable is the Linux Kernel? Analyzing two decades of feature-model history.ACM Trans. Softw. Eng. Methodol.(April 2025). https://doi.org/10.1145/3729423 Just Accepted

    work page doi:10.1145/3729423 2025

  26. [26]

    Hsuan-Chi Kuo, Jianyan Chen, Sibin Mohan, and Tianyin Xu. 2020. Set the configuration for the heart of the OS: On the practicality of operating system kernel debloating. 4, 1, Article 03 (may 2020), 27 pages. https://doi.org/10.1145/ 3379469

    2020

  27. [27]

    Rob Landley. 2006. Toybox. http://landley.net/toybox/#12-08-2022

    2006

  28. [28]

    Jörg Liebig, Sven Apel, Christian Lengauer, Christian Kästner, and Michael Schulze. 2010. An analysis of the variability in forty preprocessor-based software product lines(ICSE ’10). Association for Computing Machinery, New York, NY, USA, 105–114. https://doi.org/10.1145/1806799.1806819

    work page doi:10.1145/1806799.1806819 2010

  29. [29]

    Felix Loesch and Erhard Ploedereder. 2007. Optimization of variability in software product lines. In11th International Software Product Line Conference (SPLC 2007). 151–162. https://doi.org/10.1109/SPLINE.2007.31

    work page doi:10.1109/spline.2007.31 2007

  30. [30]

    Felix Loesch and Erhard Ploedereder. 2007. Restructuring variability in software product lines using concept analysis of product configurations. In11th European Conference on Software Maintenance and Reengineering (CSMR’07). 159–170. https: //doi.org/10.1109/CSMR.2007.40

    work page doi:10.1109/csmr.2007.40 2007

  31. [31]

    Lopez-Herrejon and Don Batory

    Roberto E. Lopez-Herrejon and Don Batory. 2001. A standard problem for evalu- ating product-line methodologies. InGenerative and Component-Based Software Engineering, Jan Bosch (Ed.). Springer Berlin Heidelberg, Berlin, Heidelberg, 10–24

    2001

  32. [32]

    Hugo Martin, Mathieu Acher, Juliana Alves Pereira, Luc Lesoil, Jean-Marc Jézéquel, and Djamel Eddine Khelladi. 2021. Transfer learning across variants and versions: The case of linux kernel size.IEEE Transactions on Software Engineering 48, 11 (2021), 4274–4290. https://doi.org/10.1109/TSE.2021.3116768

    work page doi:10.1109/tse.2021.3116768 2021

  33. [33]

    M Douglas McIlroy, J Buxton, Peter Naur, and Brian Randell. 1968. Mass-produced software components. InProceedings of the 1st international conference on software engineering (NATO), Garmisch, Germany. 88–98

    1968

  34. [34]

    Johann Mortara, Xhevahire Tërnava, and Philippe Collet. 2020. Mapping features to automatically identified object-oriented variability implementations: the case of ArgoUML-SPL(VaMoS ’20). Association for Computing Machinery, New York, Preprint, , Tërnava et al. NY, USA, Article 20, 9 pages. https://doi.org/10.1145/3377024.3377037

    work page doi:10.1145/3377024.3377037 2020

  35. [35]

    Iulian Neamtiu, Jeffrey S Foster, and Michael Hicks. 2005. Understanding source code evolution using abstract syntax tree matching. InProceedings of the 2005 international workshop on Mining software repositories. ACM, NY, USA, 1–5

    2005

  36. [36]

    Hung Viet Nguyen, Christian Kästner, and Tien N. Nguyen. 2014. Exploring variability-aware execution for testing plugin-based web applications. InPro- ceedings of the 36th International Conference on Software Engineering(Hyderabad, India)(ICSE 2014). Association for Computing Machinery, New York, NY, USA, 907–918. https://doi.org/10.1145/2568225.2568300

    work page doi:10.1145/2568225.2568300 2014

  37. [37]

    Leonardo Passos, Leopoldo Teixeira, Nicolas Dintzner, Sven Apel, Andrzej Wą- sowski, Krzysztof Czarnecki, Paulo Borba, and Jianmei Guo. 2016. Coevolution of variability models and related software artifacts.Empirical Software Engineering 21, 4 (2016), 1744–1793. https://doi.org/10.1007/s10664-015-9364-x

    work page doi:10.1007/s10664-015-9364-x 2016

  38. [38]

    Rob Pike. 2018. /bin/true used to be an empty file. The shell would open it, do nothing, and exit with a true status code. https://threadreaderapp.com/thread/ 966896123548872705.html. Accessed: 2025-04-24

    2018

  39. [39]

    Quentin Plazar, Mathieu Acher, Gilles Perrouin, Xavier Devroey, and Maxime Cordy. 2019. Uniform sampling of SAT solutions for configurable systems: Are we there yet? 240–251. https://doi.org/10.1109/ICST.2019.00032

    work page doi:10.1109/icst.2019.00032 2019

  40. [40]

    Alexander von Rhein, Jörg Liebig, Andreas Janker, Christian Kästner, and Sven Apel. 2018. Variability-aware static analysis at scale: An empirical study. 27, 4, Article 18 (nov 2018), 33 pages. https://doi.org/10.1145/3280986

    work page doi:10.1145/3280986 2018

  41. [41]

    Karlis Rokis and Marite Kirikova. 2022. Challenges of low-code/no-code soft- ware development: A literature review. InInternational Conference on Business Informatics Research. Springer, 3–17

    2022

  42. [42]

    Marco Sinnema, Sybren Deelstra, Jos Nijhuis, and Jan Bosch. 2004. Covamof: A framework for modeling variability in software product families. InInternational Conference on Software Product Lines. Springer, 197–213

    2004

  43. [43]

    Mikael Svahnberg, Jilles Van Gurp, and Jan Bosch. 2005. A taxonomy of variability realization techniques.Software: Practice and experience35, 8 (2005), 705–754. https://doi.org/10.1002/spe.652

    work page doi:10.1002/spe.652 2005

  44. [44]

    Reinhard Tartler, Daniel Lohmann, Julio Sincero, and Wolfgang Schröder- Preikschat. 2011. Feature Consistency in Compile-Time-Configurable System Software: Facing the Linux 10,000 Feature Problem. InProceedings of the Sixth Conference on Computer Systems(Salzburg, Austria)(EuroSys ’11). Association for Computing Machinery, New York, NY, USA, 47–60. https:...

    work page arXiv 2011

  45. [45]

    Xhevahire Tërnava, Mathieu Acher, and Benoit Combemale. 2023. Specialization of run-time configuration space at compile-time: An exploratory study(SAC ’23). Association for Computing Machinery, New York, NY, USA, 1459–1468. https://doi.org/10.1145/3555776.3578613

    work page doi:10.1145/3555776.3578613 2023

  46. [46]

    Xhevahire Tërnava, Mathieu Acher, Luc Lesoil, Arnaud Blouin, and Jean-Marc Jézéquel. 2022. Scratching the surface of ./configure: Learning the effects of compile-time options on binary size and gadgets. InReuse and Software Qual- ity: 20th International Conference on Software and Systems Reuse, ICSR 2022, Montpellier, France, June 15–17, 2022, Proceedings...

    work page doi:10.1007/978-3-031-08129-3_3 2022

  47. [47]

    Xhevahire Tërnava and Philippe Collet. 2017. On the diversity of capturing variability at the implementation level. InProceedings of the 21st International Systems and Software Product Line Conference-Volume B. 81–88. https://doi.org/ 10.1145/3109729.3109733

    work page doi:10.1145/3109729.3109733 2017

  48. [48]

    Xhevahire Tërnava, Johann Mortara, Philippe Collet, and Daniel Le Berre. 2022. Identification and visualization of variability implementations in object-oriented variability-rich systems: a symmetry-based approach.Automated Software Engi- neering29, 1 (2022), 1–51. https://doi.org/10.1007/s10515-022-00329-x

    work page doi:10.1007/s10515-022-00329-x 2022

  49. [49]

    Vincent Vidal. 2011. YAHSP2: Keep it simple, stupid.Proceedings of the 7th International Planning Competition (IPC-2011)(2011), 83–90

    2011

  50. [50]

    Tianyin Xu, Long Jin, Xuepeng Fan, Yuanyuan Zhou, Shankar Pasupathy, and Rukma Talwadker. 2015. Hey, you have given me too many knobs!: Understanding and dealing with over-designed configuration in system software. InProceedings of the 2015 10th Joint Meeting on Foundations of Software Engineering. 307–319. https://doi.org/10.1145/2786805.2786852

    work page doi:10.1145/2786805.2786852 2015

  51. [51]

    Zuoning Yin, Xiao Ma, Jing Zheng, Yuanyuan Zhou, Lakshmi N Bairavasundaram, and Shankar Pasupathy. 2011. An empirical study on configuration errors in commercial and open source systems. InProceedings of the Twenty-Third ACM Symposium on Operating Systems Principles. 159–172. https://doi.org/10.1145/ 2043556.2043572

    work page arXiv 2011

  52. [52]

    Bo Zhang and Martin Becker. 2012. Code-based variability model extraction for software product line improvement(SPLC ’12). Association for Computing Machinery, New York, NY, USA, 91–98. https://doi.org/10.1145/2364412.2364428

    work page doi:10.1145/2364412.2364428 2012

  53. [53]

    Bo Zhang, Martin Becker, Thomas Patzke, Krzysztof Sierszecki, and Juha Erik Savolainen. 2013. Variability evolution and erosion in industrial product lines: A case study(SPLC ’13). Association for Computing Machinery, New York, NY, USA, 168–177. https://doi.org/10.1145/2491627.2491645

    work page doi:10.1145/2491627.2491645 2013