TLDR: A study on 401 open-source projects reveals that pre-trained models (PTMs) introduce a new type of software dependency, “Software Dependencies 2.0.” It finds that projects often reuse multiple PTMs, which can be interchangeable or complementary, but their declarations are fragmented. The study identifies three main PTM reuse pipeline types (feature extraction, generative, discriminative) and four interaction patterns between PTMs and other models (feature handoff, feedback guidance, evaluation, post-processing refinement). The findings highlight significant challenges in managing, documenting, and maintaining these model-centric dependencies, underscoring the need for better tools and practices in ML-enabled software development.
The world of software development is constantly evolving, and with the rapid advancement of artificial intelligence, a new paradigm of dependencies is emerging. A recent study titled Software Dependencies 2.0: An Empirical Study of Reuse and Integration of Pre-Trained Models in Open-Source Projects by Jerin Yasmin, Wenxin Jiang, James C. Davis, and Yuan Tian delves into this shift, coining the term “Software Dependencies 2.0” to describe the integration of pre-trained models (PTMs) into modern software systems.
Traditionally, software dependencies referred to libraries and packages—collections of human-written code. These are what the researchers call “Software Dependencies 1.0.” They are typically managed with clear versioning and manifest files. However, PTMs are different. They encapsulate learned behaviors, trained on vast datasets, and come with their own architectures, parameters, and associated artifacts. Integrating these “model-centric” components introduces a new layer of complexity, posing potential threats to the maintainability and reliability of software that increasingly relies on them.
The research team set out to understand how open-source projects manage and integrate these PTMs. They focused on three key questions: how PTM dependencies are structured and documented, what stages and patterns emerge in their reuse pipelines, and how PTMs interact with other learned components. To answer these, they conducted a comprehensive analysis of 401 GitHub repositories from the PeaTMOSS dataset, which includes projects reusing PTMs from popular platforms like Hugging Face and PyTorch Hub.
Key Findings from the Study
One of the most significant findings is the prevalence of multi-PTM reuse. Over half (52.6%) of the projects studied incorporated more than one pre-trained model. Within these projects, PTMs often had distinct relationships: 37% were found to be “interchangeable,” meaning one model could seamlessly replace another for a similar task, while 23% were “complementary,” performing different functional roles within the same project.
However, the way these dependencies are declared is far from standardized. The study revealed fragmented documentation practices, with only 21.2% of projects explicitly documenting their PTMs outside of the source code itself. This means that crucial information about which models are used, and how, is often scattered across code, configuration files, and even README documents, making traceability a significant challenge. Furthermore, explicit versioning of PTMs was rare, with only 12% of projects specifying a model version, which can hinder reproducibility and long-term maintenance.
The researchers also identified three dominant types of PTM reuse pipelines: feature extraction, generative, and discriminative. These pipelines involve varying degrees of adaptation, from using a PTM “as-is” to modifying its architecture or adding new components. This highlights that PTM reuse is rarely a simple plug-and-play operation; customization is often necessary to align models with specific project requirements.
Finally, the study shed light on how PTMs interact with other models. In 50% of the projects, PTMs were found to interact with other learned components. Four main interaction types were identified: “feature handoff,” where one model’s output feeds into another; “feedback guidance,” where a PTM provides supervisory signals during another model’s training; “evaluation,” where a PTM is used solely to assess the quality of another model’s outputs; and “post-processing refinement,” where a PTM refines or validates the output of another model after its primary task. These interactions introduce considerable architectural complexity, with varying degrees of coupling between models.
The Shift to Software Dependencies 2.0
The study underscores a fundamental shift from code-centric to model-centric dependencies. Unlike traditional libraries, PTMs introduce semantic edges in dependency graphs, where the meaning and behavior are shaped by how they are reused and interact within a pipeline. This leads to higher configuration costs, more fluid and context-dependent behaviors, and new model-specific risks like data contamination or adversarial attacks.
The findings highlight several maintenance challenges, including “dependency debt” due to informal linking and missing version identifiers, “configuration debt” from scattered model settings, and “pipeline debt” from the complex, multi-stage workflows. These issues collectively emphasize the need for a re-evaluation of traditional software engineering abstractions like modules and interfaces in the context of AI-enabled systems.
Also Read:
- Understanding Why Code Changes: A Large-Scale Study with AI
- Navigating the New Era of Software Development: Structured Agentic Software Engineering
Implications for the Future
This groundbreaking research provides a foundational understanding of Software Dependencies 2.0. It calls for enhanced tools and practices that treat PTMs as first-class, modular components. For developers, this means adopting structured practices for tracking and versioning PTMs, documenting adaptations, and implementing robust integration tests. PTM hub providers are urged to offer immutable, versioned snapshots, structured changelogs, and rich metadata to improve traceability. MLOps platform providers need to become “PTM-aware,” tracking model metadata, adaptation history, and providing observability mechanisms for complex, multi-model pipelines.
Ultimately, this study paves the way for future research in areas such as robust dependency management for PTMs, extending software quality frameworks to account for the unique PTM lifecycle, and developing methods for safe model substitution and coordination across heterogeneous models. As AI continues to integrate into every aspect of software, understanding and effectively managing Software Dependencies 2.0 will be crucial for building reliable, maintainable, and trustworthy systems.
