REM: Visualizing the Ripple Effect on Dependencies Using Metrics of Health
Bibliographic record
Abstract
In recent years, free and open source software (FOSS) components have become common dependencies in the development of software, both open source and proprietary. As the complexity of software increases, so does the number of components they depend upon; in addition, components are also depending on other components. Thus, their dependency graphs are growing in size and complexity. One of the current challenges in software development is that it is not trivial to know the full dependency graph of an application. Developers are usually aware of the direct dependencies their application requires, but might not be fully aware of the dependencies that those dependencies require (the transitive dependencies). Unfortunately, transitive dependencies can break any software application; therefore, project developers need tools, methods and visualizations to inspect the health of these transitive dependencies and their potential impact.In this work, we propose the Ripple Effect of Metrics (REM) dependency graphs, a visualization of dependency graphs that leverages metrics of the health of dependencies. The two main features of REM dependency graph are: first, to display, and potentially summarize, the full dependency graph of an application based on the health of each of its dependencies; and second, to evaluate the ripple effect of potentially risky dependencies on the rest of the dependency graph. The REM helps application developers inspect the health of all of its dependencies, and also the impact that some of these dependencies might have. By showcasing two examples of popular NPM JavaScript application, we demonstrate that the combination of the ripple effect on the dependency graph using health metrics activity can be beneficial to developers. The advantages of REM graphs are: 1) the metric of health annotation is useful for evaluating the health of dependencies, and 2) the ripple effect of a vulnerability provides an easy method to identify potential risk in a dependency chain and 3) the summarizing mechanisms of the REM help reduce the size and complexity of the large dependency graphs, while focusing in specific aspects of the health of the dependency graph.
Fetched live from OpenAlex and de-inverted. Abstracts are not stored in this database: the inverted indexes are 8.6 GB of the frame’s 9.3 GB of text, and the host has 13 GB free.
How this classification was reachedexpand
Full frame machine prediction
Teacher imitationNot calibrated prevalence, not ground truth. Human validation pending. The Gemma side is a direct model label for every work in the frame, read from the title-only record. The Codex side is a classifier learned from the 10,348 direct Codex labels and calibrated to design-weighted sample rates; fields without enough sample support carry no Codex call. Candidate is the union of the two sides; consensus is their intersection. These outputs are machine_predicted_unvalidated and are not human labels.
Distilled classifier scores by category (both heads)
| Category | Codex | Gemma |
|---|---|---|
| Metaresearch | 0.002 | 0.010 |
| Meta-epidemiology (narrow) | 0.002 | 0.000 |
| Meta-epidemiology (broad) | 0.000 | 0.001 |
| Bibliometrics | 0.005 | 0.002 |
| Science and technology studies | 0.001 | 0.001 |
| Scholarly communication | 0.002 | 0.003 |
| Open science | 0.001 | 0.002 |
| Research integrity | 0.001 | 0.001 |
| Insufficient payload (model declined to judge) | 0.005 | 0.001 |
Machine scores (provisional)
The two teacher heads of the student model, read on this work. A score orders the frame for review; it never asserts a category, and the validation status ships verbatim with every row.
Baseline scores from an immature model (maturity gate not passed, 7 training rounds). Scores rank; they never assert a category.
score_only:v0-immature-baseline · verbatim from the scoring run: score_only means the number may rank works, and no category label ships from itClassification
machine, unvalidatedMachine predicted; a candidate call from one source (direct Gemma or distilled Codex), not a consensus.
How this classification was reached, model by model and score by score, is at the end of the page under "How this classification was reached".