# Composing Resilient Software: Architectural Evolution and Collaborative Governance in JackTrip's Open-Source Journey

Sven Thielen, Chris Chafe

► To cite this version:

Sven Thielen, Chris Chafe. Composing Resilient Software: Architectural Evolution and Collaborative Governance in JackTrip's Open-Source Journey. Proceedings of the 19th Linux Audio Conference, Jun 2025, Lyon, France. hal-05096030

HAL Id: hal-05096030

https://hal.science/hal-05096030v1

Submitted on 3 Jun 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# COMPOSING RESILIENT SOFTWARE: ARCHITECTURAL EVOLUTION AND COLLABORATIVE GOVERNANCE IN JACKTRIP'S OPEN-SOURCE JOURNEY

Sven Thielen*

Niederrhein University of Applied Sciences
Mönchengladbach, Germany

sven.thielen@hs-niederrhein.de

Chris Chafe†

Center for Computer Research in Music and Acoustics (CCRMA)
Stanford University, USA

lac@ccrma.stanford.edu

## ABSTRACT

Software architecture erosion poses critical risks for real-time audio systems, where strict latency requirements and legacy dependencies contribute to technical debt. This paper investigates erosion symptoms in JackTrip, an open-source tool for networked music collaboration, during its pivotal evolution from academia to commercial use through a mixed-methods case study. Analyzing 19 historical versions (2015–2022) using architectural recovery, static code analysis, and developer interviews, we uncover a paradox: metrics like cluster coverage stabilized, while link overload architectural smells surged. The COVID-19 pandemic accelerated commercialization and feature development (e.g., Virtual Studios) inducing governance fragmentation between stakeholders. Protocol constraints and framework dependencies, including IPv4 workarounds and tight coupling to JACK/Qt, impaired modernization efforts.

Key contributions include (1) evidence that architectural stabilization metrics can mask smell proliferation in rapidly evolving systems, (2) identification of hybrid governance models as catalysts for architectural drift, and (3) practical mitigation strategies tailored for audio software. We demonstrate how tools like ARCADE Core enable proactive erosion detection while Architecture Decision Records (ADR s) facilitate in documenting trade-offs (e.g., IPv6 transition costs vs. backward compatibility). For the open-source audio community, we advocate latency-aware modular decomposition and collaborative governance frameworks to balance real-time performance with sustainable design. This study provides actionable insights for maintaining architectural integrity in systems straddling research innovation and production-grade reliability.

## 1. INTRODUCTION

Software architecture serves as the structural backbone of systems, balancing technical decisions against evolving organizational and environmental contexts [1]. While principles like modularity, loose coupling, and cohesion aim to balance adaptability with stability [2], domain-specific systems face unique challenges. Real-time audio software, such as networked music collaboration tools, exemplifies this tension: strict low-latency requirements and reliance on specialized frameworks (e.g., JACK Audio Connection Kit<fnref n="1" />) often prioritize immediacy over structural hygiene. These systems accumulate technical debt through protocol optimizations and legacy dependencies, rendering them particularly vulnerable to architecture erosion.

JackTrip, a widely adopted tool for low-latency audio streaming via the User Datagram Protocol (UDP), embodies these challenges. Originating as both a research instrument and artistic platform [3], its architecture evolved through conflicting priorities: academic experimentation, pandemic-driven commercialization, and community-driven open-source development. The 2020 governance split into the nonprofit JackTrip Foundation and commercial JackTrip Labs intensified architectural drift, as rapid feature additions (e.g., cloud-based Virtual

Studios) clashed with legacy protocol constraints. This duality positions JackTrip as an ideal case study to investigate erosion dynamics in systems balancing real-time rigor with sustainability.

In this paper, we analyze JackTrip's architectural evolution across 19 historical versions (2015–2022) through a mixed-methods approach. This temporal scope captures a pivotal phase in JackTrip's evolution, encompassing its transition from academia to commercial use during the COVID-19 pandemic. Limiting the study to this bounded period ensures methodological transparency, enabling readers to interpret findings within the technological and organizational context of the referenced versions. We quantify structural trends (e.g., surging architectural smells) alongside paradoxically stabilizing modularity metrics. Semi-structured interviews with key developers reveal potential erosion drivers: rushed pandemic-era evolution, fragmented governance, and protocol technical debt from IPv4 workarounds. Our findings highlight the importance to raise awareness of the erosion phenomenon and underscore the need for domain-specific mitigation strategies.

We contribute three actionable insights: (1) Architectural recovery and analysis tools enable early erosion detection in real-time systems, (2) Governance frameworks must reconcile stakeholder priorities to prevent fragmentation, and (3) Architecture Decision Records (ADR s) institutionalize knowledge to communicate trade-offs for balancing latency requirements with modernization. By contextualizing erosion within audio software's unique constraints, we advocate for practices that harmonize real-time rigor with long-term resilience, offering lessons for open-source projects navigating dual identities as research tools and production systems.

## 2. SOFTWARE ARCHITECTURE FUNDAMENTALS

### 2.1. Foundations and Evolution of Software Architecture

The definition of software architecture by Perry and Wolf as a "set of architectural elements" [4] has evolved with the contextual impact of organization, environment, and lifecycle [2]. Effective architecture requires orchestration of modules, dependencies, and structural integrity. At its core, modularity governs architectural sustainability through coupling and cohesion [2]. Loose coupling synchronizes interdependent modules minimizing maintenance overheads, while cohesion ensures integrity through self-contained functional units. Martin [5] refines this through stability, with dependencies flowing toward architecturally stable foundations to minimize frequent adaption.

While structural hygiene constitutes a critical dimension of software architecture, Richards and Ford stress that "why is more important than how" [1]. They systematize software architecture through four pillars: architectural styles, characteristics, decisions, and design principles. Architectural styles [6, 5] provide reusable frameworks of the overall structure, contrasting with antipatterns like the chaotic "big ball of mud" [1]. Clean architecture's dependency inversion isolates business logic as a central leitmotif, while ISO 9126's quality model prioritizes maintainability and portability, diverging from practitioner-focused characteristics like scalability and legal compliance [7]. Every

<footnote>* This work extends research from the author's master's thesis.</footnote>

<footnote>† Many thanks to JackTrip Labs, Inc. and the JackTrip Foundation.</footnote>

<footnote n="1">¹https://jackaudio.org/</footnote>
architectural decision embodies trade-offs [1]. Design principles like SOLID [5] guide implementation, while environmental factors—infrastructure, budgets, and methodologies like Test-Driven Design—shape evolutionary cadence. A sustainable architecture thus targets equilibrium—structured yet adaptable, precise yet contextually resonant.

## 2.2. Understanding Architecture Erosion

Technical debt arises when developers prioritize speed over quality, implementing expedient solutions (e.g., temporary code fixes, architectural compromises) to meet deadlines. Unresolved technical debt incurs compound interest over time, creating escalating maintenance overhead that inhibits developmental velocity and contributes to the increase of bugs. Ignoring it results in systems that progressively become harder to modify (developers struggle with bug fixes, new features). Sustaining quality requires constant refactoring to keep the system harmonized within a "corridor of low debt." [8]

Architecture erosion describes the gradual degradation of a system's intended design as requirements shift and complexity escalates [9]. Deviations from architectural boundaries (e.g., code violating layered abstractions) or intentional compromises (e.g., prioritizing releases over quality) distort the system's integrity. This process is independent of system scale: smaller systems may degrade through localized misalignments, while larger systems might retain coherence despite incremental compromises. Architecture erosion often begins insidiously [10], evading detection until maintenance efforts intensify, as the system's structure deviates from its foundational design goals.

## 2.3. Common Symptoms: Architectural Smells

Architectural smells represent suboptimal design decisions that degrade structural integrity within software systems. These smells correlate with architecture erosion, as they can originate from flawed high-level design decisions and manifest as symptoms of degradation [10]. Architectural smells disrupt modularity and coupling, propagating systemic entropy. Though smells must not necessarily become an actual issue, their resolution most probably supports in mitigating architecture erosion.

For instance, dependency cycles violate modularity principles by creating circular dependencies between components [11]. Modifying one component in such a cycle triggers cascading changes across interconnected modules. Similarly, link overload occurs when a component accumulates excessive dependencies [12], creating bottlenecks and increasing the risk of systemic fragmentation.

## 2.4. Possible Reasons For Architecture Erosion

According to Baabad et al. [13], architectural smells rank as the second most prevalent symptom of architecture erosion. These smells often originate from rushed evolution—the primary cause of architecture erosion—where expedited timelines force developers to prioritize speed over structural soundness. Successive system versions accumulate unresolved architectural smells, degrading design coherence over time.

Recurring changes, the second-leading cause, introduce instability when new technologies or features are implemented without alignment to the system's core design [13]. Similarly, a lack of developer awareness leads to architectural violations, as inexperienced contributors introduce code that conflicts with the system's foundational structure.

In academic environments, Laser et al. [14] describe the evolution of research tools as a fragmented ecosystem of single solutions (islands) constituting a "software archipelago." Small prototypes, initially developed as proof-of-concept tools, expand into large, long-lived systems (3L-ARTS) driven by short-term goals (e.g., "publish or perish" mindset and associated con-

straints), often neglecting architectural cohesion. Over time, these systems become tightly coupled, burdened by inconsistent design choices and systemic fragmentation.

# 3. CASE STUDY: EROSION SYMPTOMS AND CAUSES IN JACKTRIP VERSIONS 1.1–1.6.8

We conducted a longitudinal study [15] to diagnose erosion patterns in JackTrip, employing methods to measure decay, identify symptoms, and analyze contributing factors.

## 3.1. Methodology

We employed a mixed-methods approach [16], integrating static code analysis of 19 historical JackTrip versions (2015–2022; selected to capture JackTrip’s pivotal transition from academic prototype to production-grade software) with semi-structured interviews of key contributors in 2023.

Architectures were recovered via the Algorithm for Comprehension-Driven Clustering (ACDC) [17] and analyzed via ARCADE Core<fnref n="2" />, an open-source tool under development. In order to identify the overall architectural change, we assessed the similarity of architectures and clusters from one version to another using the architecture-to-architecture (a2a) and cluster coverage (cvg) metrics, respectively. The measurement of architectural instability and quantification of dependency smells (link overload, dependency cycles) [11] revealed further structural trends, while dependency graphs visualized evolving cluster relationships.

We conducted semi-structured interviews with four developers representing distinct roles and tenure: an academic founder (contributing since 2000), a hobbyist (2019–present), a professional stakeholder (joined during the 2020 pandemic), and an academic/hobbyist contributor (joined before commercialization in 2020). Sessions ranged from 37 to 55 minutes, guided by open questions exploring technical debt, governance tensions, and latency trade-offs. A structured interview protocol ensured thematic focus. Transcripts, generated via OpenAI Whisper<fnref n="3" />, were manually corrected against recordings and validated by participants to ensure accuracy.

We used thematic analysis [18] to process the transcripts and triangulated the findings with the metrics and smells to validate erosion patterns. Thematic analysis followed a six-phase approach: (1) familiarization with data through iterative review and note-taking; (2) systematic coding of text segments to identify patterns; (3) grouping codes into candidate themes, (4) refined through iterative comparison and quality checks; (5) defining/naming themes; (6) and synthesizing findings with exemplary quotes. This structured process ensured rigorous interpretation of interview transcripts while maintaining alignment with the study's focus on architecture erosion symptoms and causal factors.

## 3.2. Case Overview: JackTrip's Purpose and Evolution

JackTrip, developed by Stanford's SoundWIRE group at Stanford University's Center for Computer Research in Music and Acoustics (CCRMA), enables networked music performances and investigates network acoustics via uncompressed, low-latency UDP audio streaming. It addresses IP network challenges like jitter and packet loss, which disrupt time-sensitive audio through audible artifacts. By employing buffering and silence insertion, JackTrip mitigates disruptions while repurposing latency fluctuations as creative parameters, such as virtual resonators using synthesis algorithms (e.g., Karplus-Strong, later Freeverb). This dual-use framework positions it as both a technical research tool and artistic medium [3].

<footnote n="2">²https://github.com/usc-softarch/arcade_core</footnote>

<footnote n="3">³https://github.com/openai/whisper</footnote>
Architecturally, JackTrip evolved from a modular CommonC++ design to integrate Qt<fnref n="4" /> and the Synthesis Tool-Kit (STK). The adoption of JACK enhanced deterministic low-latency processing, enabling multi-core CPU use and Mac OS portability. By 2010, demand for multi-location concerts drove the development of a hub mode—a "multi-client concurrent server" using TCP for session coordination and dynamic UDP ports for scalable audio routing. This design centralized mixing and channel management enabling dynamic gain adjustments [19].

Rooted in Stanford's CCRMA—a hub for music-technology innovation—JackTrip reflects interdisciplinary traditions like FM synthesis and contributions to open-source audio software via Planet CCRMA [20]. The COVID-19 pandemic accelerated its transition to production-grade infrastructure, driven by community contributions (e.g., QJackTrip's GUI) and institutional-commercial partnerships. The nonprofit JackTrip Foundation now maintains core open-source code, while JackTrip Labs<fnref n="5" /> offers cloud-based "Virtual Studio" subscription services to ease session setup for the average musician, illustrating a stakeholder ecosystem blending art, technology, and open-source collaboration [21].

### 3.3. Architectural Decay Patterns

The Algorithm for Comprehension-Driven Clustering (ACDC) recovery method organizes source files into modular clusters, representing bodyheader file pairs as circular nodes annotated with filenames and paths. Directed edges denote dependency relationships between these clusters. Our ACDC-derived visualizations reveal incremental architectural changes across Jack-Trip versions, particularly highlighting feature-driven dependency growth.

Figure 1 demonstrates this characteristic for architectural changes from version 1.5.3 to 1.6.0. Red clusters mark components introduced in version 1.6.0 indicating the Virtual Studio feature, while blue edges indicate new inter-module dependencies. Subsequent analysis of version 1.6.8 (Fig. 2) shows how these initial additions evolved, particularly noting the dependency dispersion within the codebase by additional Virtual Studio related clusters (e.g., src/gui/vsDevice.ch) [22].

<figure><img src="image_2.png" /><figcaption>Figure 1: Version 1.6.0 architecture with introduced clusters (red) and new dependencies (blue) since version 1.5.3. A larger version of this figure is available in the appendix as Fig. 4.</figcaption></figure>

<figure><img src="image_3.png" /><figcaption>Figure 2: Cluster evolution from version 1.5.3 to version 1.6.8. Sustained growth of new dependencies (blue) and peripheral cluster additions (red). A larger version of this figure is available in the appendix as Fig. 4.</figcaption></figure>

The accumulation of code smells identified through static code analysis points to progressive architecture erosion. Link overload smells surge from 1 to 11 between versions 1.1 and 1.6.8 (Figure 3). Specific releases (v1.3.0, v1.4.0, v1.6.0, and v1.6.2) mark their introduction and persistence up to the last version we investigated (v1.6.8). Dependency cycles decrease from 2 to 1. However, the persistent dependency cycle smell includes clusters related to the Virtual studio feature after its inception in version 1.6.0 which have been previously identified to disperse dependencies using the visualizations [22].

<figure><img src="image_4.png" /><figcaption>Figure 3: Architectural smells in JackTrip's evolution.</figcaption></figure>

In contrast to the smells trend, the metrics (Table 1) show a path towards stabilization. Architectural instability declines from 0.56 to 0.42, while architecture-to-architecture (a2a) and cluster coverage (cvg) metrics consistently reach 100% from version 1.4.1 onward, indicating architectural stabilization and cluster consistency in later JackTrip versions. Notable deviations occur in version 1.3.0, where sharply lower a2a (57.64%) and cvg (57.90%) align with a temporary architectural instability spike (0.58). Lower a2a correlates more strongly with instability reduction and new link overload smells in subsequent releases, reflecting an erosion paradox during evolution [22].

### 3.4. Environmental and Organizational Factors

The interviews identify seven interrelated causes for architecture erosion and potential drivers. We outline the most relevant here. JackTrip's academic origins and real-time audio focus increase risks of architecture erosion. Its evolution accelerated during the COVID-19 pandemic in 2020 due to urgent demand for remote music collaboration, driving commercialization and usability improvements, as described by the interviewees.

<footnote n="4">⁴https://wwwovi.io/</footnote>

<footnote n="5">⁵https://www.jacktrip.com/</footnote>
<table><caption>Table 1: Architectural metrics for JackTrip versions 1.1–1.6.8 (2015–2022) using ACDC recovery. Metrics include Architecture-to-architecture (a2a), Cluster coverage (cvg), and Architectural Instability (Arch Inst).</caption><thead><tr><th>Release Date</th><th>Version</th><th>a2a</th><th>cvg</th><th>Arch Inst</th></tr></thead><tbody><tr><td>2015-05-27</td><td>1.1</td><td>-</td><td>-</td><td>0.56</td></tr><tr><td>2020-06-07</td><td>1.2</td><td>92.76</td><td>89.47</td><td>0.56</td></tr><tr><td>2020-08-05</td><td>1.3.0</td><td>57.64</td><td>57.90</td><td>0.58</td></tr><tr><td>2021-11-02</td><td>1.4.0</td><td>83.22</td><td>95.24</td><td>0.53</td></tr><tr><td>2021-11-11</td><td>1.4.1</td><td>100</td><td>100</td><td>0.53</td></tr><tr><td>2021-12-05</td><td>1.4.2</td><td>98.43</td><td>100</td><td>0.52</td></tr><tr><td>2021-12-19</td><td>1.4.3</td><td>100</td><td>100</td><td>0.52</td></tr><tr><td>2022-01-03</td><td>1.5.0</td><td>100</td><td>100</td><td>0.52</td></tr><tr><td>2022-01-07</td><td>1.5.1</td><td>100</td><td>100</td><td>0.52</td></tr><tr><td>2022-03-02</td><td>1.5.2</td><td>97.53</td><td>96.43</td><td>0.52</td></tr><tr><td>2022-03-28</td><td>1.5.3</td><td>100</td><td>100</td><td>0.52</td></tr><tr><td>2022-06-01</td><td>1.6.0</td><td>90.25</td><td>100</td><td>0.47</td></tr><tr><td>2022-06-21</td><td>1.6.1</td><td>100</td><td>100</td><td>0.47</td></tr><tr><td>2022-08-17</td><td>1.6.2</td><td>93.59</td><td>100</td><td>0.44</td></tr><tr><td>2022-08-23</td><td>1.6.3</td><td>100</td><td>100</td><td>0.44</td></tr><tr><td>2022-09-16</td><td>1.6.4</td><td>98.03</td><td>100</td><td>0.44</td></tr><tr><td>2022-11-02</td><td>1.6.6</td><td>95.69</td><td>100</td><td>0.44</td></tr><tr><td>2022-12-02</td><td>1.6.7</td><td>97.69</td><td>100</td><td>0.42</td></tr><tr><td>2022-12-06</td><td>1.6.8</td><td>100</td><td>100</td><td>0.42</td></tr></tbody></table>

Early governance ambiguity between JackTrip Labs and the OSS project initially caused instability, as uncoordinated commits from volunteers and commercial developers have generated synchronization risks. Disproportionate contributions from full-time commercial teams—employing systematic bug resolution (e.g., automated package checks) and Scrum workflows—contrast with transient OSS engagement patterns, where volunteers address niche features or maintenance tasks. While process refinements (shorter commit cycles, enforced pull requests) mitigated merge conflicts, tensions persisted between JackTrip Labs’ customer-driven prioritization due to Virtual Studio related development and the OSS community’s passion-driven, ad hoc contributions [22].

Legacy architectural decisions, particularly tight coupling via Qt’s signals/slots and CLI/GUI "double management" of settings complicates modernization efforts. JackTrip Labs’ push for microservices and modern C++ standards clashes with the OSS codebase’s entangled cross-platform code (e.g., OS-specific macros), while usability improvements like the GUI from QJackTrip tend to have introduced redundant logic. Interviewees advocate decoupling core protocol logic into a shared library, separating it from application layers (CLI/GUI, client/server). This approach would reduce platform-specific code fragmentation while the HackTrip prototype—a Qt 6/RtAudio rebuild—is considered as a template for incremental refactoring. Despite consensus, framework dependencies (e.g., JACK) and backward compatibility requirements delay full realization of this vision [22].

JackTrip’s protocol evolution efforts reveal tensions between modern usability demands and its foundational low-latency requirements (e.g., minimal headers and small packets optimized for 2000s-era bandwidth constraints). Early design choices, such as non-compliant IPv4 port-binding, prioritized real-time performance but created technical debt that hindered IPv6 compatibility and extensibility (e.g., lacking version negotiation or dedicated MIDI channels). While developers agree on modernizing the protocol, progress stalls primarily due to insufficient documentation. Concurrently, JackTrip Labs has shifted focus toward accessibility leveraging geolocated Virtual Studio rooms to reduce latency, underscoring the challenge of balancing real-time audio fidelity with broader adoption through usability improvements [22].

## 3.5. Implications for JackTrip’s Architecture

The most significant architectural change occurs in version 1.3.0, which corroborates with interviewees’ perception of a rapid evolution during the pandemic. This aligns with the increase of the architectural smells trend, mirroring Baabad et al.’s second most observed symptom of architecture erosion during a rushed evolution [13]. However, version 1.6.0 marks another significant spike of link overload smells, correlating with the introduction of the Virtual Studio feature by JackTrip Labs.

JackTrip Labs’ adoption of modern practices (e.g., microservices, newer C++ standards) clashes with dependencies (e.g., JACK, Qt) from earlier design choices, contributing to the risk of a fragmented architecture, as described by Laser et al.’s archipelago model of independently evolving "islands" [14]. The original protocol’s lack of formal specifications and versioning led to workarounds (e.g., during IPv6 adoption), complicating modernization while maintaining user trust. Such efforts mirror the tension between preserving backward compatibility while advancing infrastructure for future needs and foster innovation. Balancing these priorities remains key to sustaining JackTrip’s evolution while honoring its technical roots.

## 4. LESSONS LEARNED AND MITIGATION STRATEGIES

Our study shows how employing architectural recovery and analysis facilitates diagnosing potential architecture erosion. Metrics like link overload and dependency cycles can provide early warnings of decay, while visualizations expose dispersion trends. Regular architectural assessments can support projects in balancing innovation with sustainability, particularly during transitions (e.g., academic-to-commercial). Software architecture recovery and analysis, as exemplified by our case study, is considered as the first step in a mitigation strategy with technical debt removal and countermeasure implementation described by Link et al. [23].

Contextual background and reasons for architecture erosion can be investigated using semi-structured interviews with developers. We employed a mixed-methods approach for triangulation and to better understand the underlying reasons of potential issues, as well as to investigate the perception of erosion symptoms and causes (e.g., rushed evolution). Our findings highlight the need for governance frameworks that reconcile divergent stakeholder priorities. Proposals like protocol versioning and separation of the core functionality and end application suggest pathways to find technical solutions. However, a lack of documentation and trade-offs regarding the real-time focus of JackTrip remain challenges in its evolution.

We propose the adoption of Architecture Decision Records (ADRs)<fnref n="6" /> to institutionalize knowledge, reduce ambiguity, and ensure architectural integrity as systems scale. Embedding ADRs in version-controlled repositories (e.g., Git) or wikis enhances traceability, while concise pros-and-cons discussions foster alignment on trade-offs, such as usability versus low-latency prioritization. For instance, an ADR might document IPv6 transition trade-offs, mirroring retrospective analysis of IPv4 workarounds to address JackTrip’s protocol documentation gaps.

## 5. CONCLUSION: TOWARD SUSTAINABLE ARCHITECTURES IN AUDIO SOFTWARE

The investigated historical system versions in JackTrip’s evolution underscore the fragile balance between innovation and architectural integrity in open-source audio software. The project’s pandemic-driven acceleration, marked by features like Virtual Studio and governance tensions between stakeholders, reveal

<footnote n="6">⁶https://adr.github.io</footnote>
how rapid growth induces architecture erosion, even as modu-
larity metrics suggest stabilization. Legacy dependencies, pro-
tocol limitations, and fragmented priorities exemplify systemic
challenges faced by real-time systems, where technical debt can
accumulate over time.

Mitigating architecture erosion demands proactive strate-
gies: We propose adopting ADRs to document trade-offs trans-
parently, using tools like ARCADE Core for early decay de-
tection, and harmonize backward compatibility with modern-
ization. However, audio software's architectural sustainability
depends on domain-specific requirements and may not bene-
fit from immediate mitigation. For instance, strict low-latency
guarantees often force tight coupling to available frameworks
(e.g., JACK) and simple network protocols (e.g., UDP) while
creative workarounds may accumulate technical debt to circum-
vent unsolved technical challenges.

The dual identity of tools like JackTrip, which navigates cre-
ative experimentation and commercial reliability, distorts gov-
ernance priorities: academic contributors may emphasize ex-
perimental features, while commercial stakeholders want sta-
bility, resulting into architectural drift. These challenges de-
mand tailored mitigation strategies, such as latency-aware mod-
ular decomposition and explicit documentation of perceptual
trade-offs in ADRs. By foregrounding audio's unique needs,
the open-source community can advance domain-specific archi-
tectural practices that harmonize real-time rigor with long-term
resilience.

6. ACKNOWLEDGMENTS

We thank JackTrip contributors, users and JackTrip Labs for collaboration, and Stanford's CCRMA for fostering interdisciplinary innovation. This work utilized the ARCADE Core toolset, revitalized by Marcelo Schmitt Laser, whose expertise in software architecture and responsiveness to technical requests facilitated robust structural analysis. We acknowledge his indispensable contributions to this research.

7. REFERENCES

[1] Mark Richards and Neal Ford, *Fundamentals of Software Architecture*, O'Reilly, 2020.

[2] Arne Koschel, Andreas Rausch, and Mahbouba Gharbi, *Software Architecture Fundamentals*, 3 edition, 2019.

[3] Chris Chafe, "I am Streaming in a Room," *Frontiers in Digital Humanities*, vol. 5, 2018.

[4] Dewayne E. Perry and Alexander L. Wolf, "Foundations for the study of software architecture," *SIGSOFT Softw. Eng. Notes*, vol. 17, no. 4, pp. 40–52, 1992.

[5] Robert C. Martin, *Clean Architecture: A Craftsman's Guide to Software Structure and Design*, Pearson, 2017.

[6] Eric Evans, *Domain-Driven Design: Tackling Complexity in the Heart of Software*, Addison-Wesley Professional, 2003.

[7] Martin Glinz, "A risk-based, value-oriented approach to quality requirements," vol. 25, no. 2, pp. 34–41.

[8] Carola Lilienthal, *Sustainable Software Architecture*, 2019.

[9] Erik Whiting and Sharon Andrews, “Drift and erosion in software architecture: Summary and prevention strategies,” in *Proceedings of the 2020 the 4th International Conference on Information System and Data Mining*. 2020, ICISDM 2020, pp. 132–138, Association for Computing Machinery.

[10] Ruiyin Li, Peng Liang, Mohamed Soliman, and Paris Avgeriou, “Understanding software architecture erosion: A systematic mapping study,” *Journal of Software: Evolution and Process*, vol. 34, no. 3, pp. e2423, 2022.

[11] Duc Minh Le, Carlos Carrillo, Rafael Capilla, and Nenad Medvidovic, “Relating architectural decay and sustainability of software systems,” in *2016 13th Working IEEE/IFIP Conference on Software Architecture (WICSA)*, 2016, pp. 178–181.

[12] D. Le, Daniel Link, Arman Shahbazian, Yixue Zhao, C. Mattmann, and N. Medvidović, “Toward a Classification Framework for Software Architectural Smells,” 2017.

[13] Ahmed Baabad, Hazura Binti Zulzalil, Sa'adah Hassan, and Salmi Binti Baharom, “Software Architecture Degradation in Open Source Software: A Systematic Literature Review,” *IEEE Access*, vol. 8, pp. 173681–173709, 2020.

[14] Marcelo Schmitt Laser, Duc Minh Le, Joshua Garcia, and Nenad Medvidović, “Architectural archipelagos: Technical debt in long-lived software research platforms,” in *2021 IEEE/ACM International Conference on Technical Debt (TechDebt)*, 2021, pp. 94–98.

[15] Robert K. Yin, *Case Study Research and Applications*, Sage Publishing, 6 edition, 2018.

[16] Per Runeson, Martin Höst, Austin Rainer, and Björn Regnell, *Case Study Research in Software Engineering*, John Wiley & Sons, Ltd, 2012.

[17] V. Tzerpos and R.C. Holt, “ACCD: an algorithm for comprehension-driven clustering,” in *Proceedings Seventh Working Conference on Reverse Engineering*, 2000, pp. 258–267, ISSN: 1095-1350.

[18] Virginia Braun and Victoria Clarke, “Thematic analysis.,,” in *APA handbook of research methods in psychology, Vol 2: Research designs: Quantitative, qualitative, neuropsychological, and biological.*, APA handbooks in psychology®, pp. 57–71. American Psychological Association.

[19] Juan-Pablo Cáceres and Chris Chafe, “JackTrip/SoundWIRE Meets Server Farm,” *Computer Music Journal*, vol. 34, no. 3, pp. 29–34, Sept. 2010.

[20] Andrew J. Nelson, *The Sound of Innovation: Stanford and the Computer Music Revolution*, The MIT Press, Mar. 2015.

[21] Marina Bosi, Antonio Servetti, Chris Chafe, and Cristina Rottondi, “Experiencing remote classical music performance over long distance: A JackTrip concert between two continents during the pandemic,” vol. 69, no. 12, pp. 934–945, 2021.

[22] Sven Thielen, “Investigating jacktrip’s software architecture: A case study on prominent reasons for architectural erosion in open source software originating from academia,” Master’s thesis, Hochschule Düsseldorf, 2023.

[23] Daniel Link, Pooyan Behnamghader, Ramin Moazeni, and Barry Boehm, “The value of software architecture recovery for maintenance,” New York, NY, USA, 2019, ISEC ’19, Association for Computing Machinery.

[24] Juan-Pablo Cáceres and Chris Chafe, “JackTrip: Under the Hood of an Engine for Network Audio,” *Journal of New Music Research*, vol. 39, no. 3, pp. 183–187, 2009.

8. APPENDIX

For improved readability of the cluster topologies and their de-
pendency relationships, expanded versions of Figures 1 and 2 are
provided in this appendix (Figures 4 and 5, respectively). These
high-resolution renderings enable detailed inspection of node la-
bels and edge connections.
<figure><img src="image_5.png" /><figcaption>Figure 4: Version 1.6.0 architecture with introduced clusters (red) and new dependencies (blue) since version 1.5.3.</figcaption></figure>

<figure><img src="image_6.png" /><figcaption>Figure 5: Cluster evolution from version 1.5.3 to version 1.6.8. Sustained growth of new dependencies (blue) and peripheral cluster additions (red).</figcaption></figure>