Dependency Dilemmas: A Comparative Study of Independent and Dependent Artifacts in Maven Central Ecosystem

Manishankar Mondal; Mehedi Hasan Shanto; Muhammad Asaduzzaman; Shaiful Chowdhury

REVIEW 5 major objections 5 minor 1 cited by

Dependency Dilemmas: A Comparative Study of Independent and Dependent Artifacts in Maven Central Ecosystem

T0 review · 5 major / 5 minor · reviewed 2026-08-16 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read Independent Maven artifacts—those no other artifact depends on—match dependent artifacts in popularity while showing far fewer total CVEs, and the paper argues they deserve a place in dependency choices.

desk verdict The paper's central safety claim rests on unnormalized CVE counts that invert per artifact, and the text contradicts its own table; the underlying zero-dependency Maven question is still worth a proper study. read the letter →

arxiv 2504.12261 v1 pith:P54FHXNJ submitted 2025-04-16 cs.SE

Mehedi Hasan Shanto , Muhammad Asaduzzaman , Manishankar Mondal , Shaiful Chowdhury This is my paper · ORCID

classification cs.SE

keywords MavenCentraldependencygraphindependentartifactssoftwarevulnerabilitiesCVEPageRankecosystemtransitivedependencies

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

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

The reading

The paper studies the 22,081 active Maven Central artifacts that no other artifact depends on—a population previous work mostly ignored—and compares them with 267,640 dependent artifacts across 18 metrics. Its central claim is that these independent artifacts are not minor: they attract comparable mean download popularity (25.58 vs. 7.30 over the past year), account for fewer total CVE records (60 vs. 179), and have zero propagated vulnerabilities, because nothing downstream can inherit a vulnerability through them. The authors conclude that independent artifacts give developers a safe, self-contained dependency alternative, provided maintainers address their slower release cadence and weaker documentation and licensing. The significance is practical: if the claim holds, dependency-minimizing projects can choose such artifacts without sacrificing popularity or inheriting transitive risk.

What carries the argument

The central object is the Maven Central dependency graph, where nodes are artifacts and edges record dependency relationships, and the partition of that graph by in-degree: artifacts with zero incoming edges are called independent, all others dependent. Two measures carry the influence argument: PageRank, a link-analysis score of how connected a node is in the dependency network, and out-degree centrality, the fraction of other artifacts a node points to. The security argument runs through CVE and CWE records attached to releases, with the propagation mechanism that an artifact with no incoming edges cannot pass a vulnerability downstream, while a dependent artifact can propagate transitively. The same graph also yields the maintenance metrics, including release counts, release frequency, dependents, and repository health, that form the comparison.

What would settle it

Take the paper's own Table II counts and divide by group size: $60/22081$ for independent artifacts versus $179/267640$ for dependent artifacts. Because the per-artifact rate is higher for the independent group, the 'fewer vulnerabilities' claim would be falsified under rate normalization; it would survive only if a severity-weighted or release-adjusted comparison still favored independent artifacts.

Watch

Extended reading notes

Core claim

Defining independent artifacts as Maven Central artifacts with zero incoming dependencies, the paper reports that they are a meaningful slice of the ecosystem (15.4% of studied artifacts, 22,081 active) and remain influential: their median PageRank (0.40) is close to that of dependent artifacts (0.44), even though their out-degree centrality is lower. On the headline metrics, the paper finds comparable popularity (25.58 vs. 7.30), fewer CVEs (60 vs. 179), and zero propagated vulnerabilities, while also finding less frequent releases (median 0.006 vs. 0.02) and weaker maintenance markers such as fewer contributors and more missing licenses. The authors conclude that independent artifacts can serve as safe, self-contained alternatives to traditional dependencies and recommend that maintainers prioritize them for updates, issue responses, and documentation.

Load-bearing premise

The security comparison treats raw CVE totals as directly comparable even though the independent group has roughly one-twelfth as many active artifacts as the dependent group, so a per-artifact rate would not support the 'fewer vulnerabilities' claim.

Editorial extensions

If this is right

Projects that want to minimize transitive risk can choose independent artifacts without conceding user adoption, since their download popularity is comparable to dependent artifacts.
Dependency chains that include an independent artifact terminate there for downstream vulnerability propagation, so a vulnerable upstream library cannot reach downstream consumers through that artifact.
Consumers of independent artifacts inherit a slower fix cadence: with a lower median release frequency, security patches take longer to arrive, so choosing them trades transitive safety for response time.
Maintainers of independent artifacts hold the key to realizing the safety benefit: regular updates, license completion, and better documentation would remove the main disadvantages the study identifies.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

In my reading of the paper's own Table II, rate-normalizing changes the security picture: the independent group has 60 CVEs across 22,081 artifacts (about 2.7 per 1,000) while the dependent group has 179 across 267,640 (about 0.7 per 1,000), so 'fewer vulnerabilities' is sensitive to whether one compares absolute or per-artifact counts.
The definition used in the paper—no incoming dependencies—does not by itself rule out outgoing dependencies, so the 'self-contained' reading should be tested against the dependency graph before treating these artifacts as dependency-free.
A comparable phenomenon may exist in other package ecosystems: if dependency-free components elsewhere also show high download counts but slow maintenance, tooling that nudges maintainers toward regular releases would address a cross-ecosystem gap.

Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

Punchline: the paper's headline vulnerability claim is based on raw counts across groups that differ by 12x, and the per-artifact rates actually favor dependent artifacts. On top of that, the text and Table II disagree on the degree-centrality numbers. The research question is real, but the evidence as presented doesn't support the conclusion.

What is new: this is the first empirical characterization I know of zero-dependency Maven artifacts as a class. The authors use the Goblin dataset, provide a replication package, and their maintainability findings—lower release frequency, fewer contributors, more missing licenses, less README coverage—are consistent and plausible. Those parts are worth keeping.

Soft spots, in order of severity. The 'fewer vulnerabilities (60 vs 179)' in the abstract compares absolute counts for 22,081 independent artifacts and 267,640 dependent artifacts. Normalized, independent artifacts have roughly 2.7 CVEs per thousand versus 0.67 per thousand for dependent artifacts; the artifacts-with-CVE row is about 3.1 vs 3.0 per thousand. So the 'safe, self-contained alternative' claim flips. Second, the paper is internally inconsistent: Section III says dependent artifacts have 793 CVEs versus 69, while the abstract and Table II use 179 versus 60. It also says the median out-degree centrality for independent artifacts is 6.3E-7 and 'notably larger' for dependent artifacts, but Table II lists the independent median at 5.04E-6—essentially equal. Those aren't cosmetic. Third, 'zero propagated vulnerabilities' is true by definition under their independence definition, not an empirical result. It also doesn't offset the higher own-vulnerability rate. Fourth, 'statistically significant' appears without any test being reported.

I agree with the reader's reject verdict. The paper needs normalized metrics, corrected tables, and real significance tests. That said, I would still send it to peer review rather than desk-reject: the question is legitimate, the dataset work is reproducible, and the maintainability observations are salvageable. With a major revision this could become a solid empirical study.

Referee Report

5 major / 5 minor

Summary. The paper analyzes 658,078 artifacts from the Maven Central ecosystem, classifying artifacts with no dependencies as 'independent' (in-degree = 0) and the rest as 'dependent.' It reports prevalence, ecosystem influence via PageRank and out-degree centrality, and compares 18 usability and maintenance metrics between the two groups. The abstract claims independent artifacts have comparable popularity, fewer vulnerabilities (60 vs. 179 CVEs), and zero propagated vulnerabilities, concluding they provide a 'safe, self-contained alternative' to traditional dependencies. Data are drawn from the Goblin dataset, and a replication package is provided.

Significance. If the findings were sound, the paper would address a genuinely under-studied population of Maven artifacts and could inform dependency-selection and maintenance decisions. The replication package and the use of a large, recent dataset are strengths. However, the central quantitative claims are undermined by a failure to normalize vulnerability counts across groups of very different sizes, by a definitional tautology in the 'zero propagated vulnerabilities' claim, and by a misreading of the centrality data. As presented, the paper's headline safety conclusion is not supported, so its significance for practitioners and researchers is currently not established.

major comments (5)

[Abstract; Section III-C; Table II] The claim 'fewer vulnerabilities (60 CVEs vs. 179 CVEs)' compares raw counts without accounting for group sizes: Table I reports 22,081 active independent artifacts versus 267,640 active dependent artifacts, a 12x difference. Per-artifact CVE rates are 60/22,081 = 2.72 per 1,000 for independent artifacts versus 179/267,640 = 0.67 per 1,000 for dependent artifacts, which reverses the claimed advantage. The NumArtifactsWithCVE row shows near-identical rates (69/22,081 = 3.1 per 1,000 versus 793/267,640 = 3.0 per 1,000). Because the paper's central recommendation depends on this comparison, the headline conclusion is unsupported as presented.
[Section III-B; Table II] The text states that the median out-degree centrality for dependent artifacts (5.06E-6) is 'notably larger' than for independent artifacts (6.3E-7). However, Table II reports the independent-artifact median as 5.04E-6; the value 6.3E-7 is the minimum, not the median. The medians are nearly identical (5.06E-6 versus 5.04E-6), so the 'notably larger' claim is not supported by the data presented. The same paragraph also asserts statistical significance without reporting any test.
[Abstract; Section III-C; Section IV] The 'zero propagated vulnerabilities' claim for independent artifacts is a direct consequence of the paper's definition: independent artifacts are defined as having no dependencies, and propagated vulnerabilities are defined as inherited from dependencies. This is a definitional equivalence, not an empirical discovery. Presenting it as a research finding overstates the contribution and should be reframed as an inherent property of the classification.
[Abstract; Section III-C] The abstract describes 'comparable popularity (25.58 vs. 7.30)' for independent versus dependent artifacts. These numbers are the means from Table II and show independent artifacts have more than three times the popularity of dependent artifacts, so describing them as 'comparable' is misleading. Either the interpretation is wrong or the wrong metric is being reported; in either case, the statement does not match the data.
[Section III-A; Section III-B; Section III-C] The paper repeatedly claims that differences are 'statistically significant' (e.g., in the PageRank and centrality discussion) but reports no significance tests, effect sizes, or confidence intervals for any of the 18 metrics. With sample sizes in the tens of thousands, trivial differences can achieve statistical significance, so the reader cannot interpret the practical importance of the reported differences without additional statistics.

minor comments (5)

[Section II] The phrase 'number of incoming dependencies' is ambiguous: in standard graph terminology, an incoming edge to an artifact represents a dependent, whereas the paper uses it to mean the artifact's own dependencies on upstream artifacts. Please clarify the definition or use a less confusing term.
[Table II] The row label 'NumAtrtifactsWithCVE' contains a typo; it should be 'NumArtifactsWithCVE'.
[Table II; Section III-C] It is unclear whether NumCVE(Last Release) and NumArtifactsWithCVE are totals, means, or per-release counts. The table header says 'Mean/Median/Min/Max' for other rows, but these two rows only show a single number, so their meaning should be stated explicitly.
[Section III-C] The sentence about release frequency states that the median release frequency for independent artifacts implies an average of 166 days between releases, but the units of ReleaseFrequency are not defined in the table. Please specify whether the metric is releases per day, per week, or another unit.
[Reference [16]] The accessed date reads '2023, Jsnuary 28'; this appears to be a typo for 'January'.

Circularity Check

1 steps flagged · score 6.0 of 10

The 'zero propagated vulnerabilities' headline is definitional: independent artifacts are defined as having no dependencies, so no vulnerabilities can propagate to them; other comparisons are empirical but undercut by group-size normalization.

self definitional [Abstract; Section II (Data Collection), artifact classification definition]
"Independent artifacts: These artifacts do not hold any dependencies with the upstream artifacts (number of incoming dependencies = 0). ... comparable popularity (25.58 vs. 7.30), fewer vulnerabilities (60 CVEs vs. 179 CVEs), and zero propagated vulnerabilities."

The group being studied is defined in Section II as artifacts that 'do not hold any dependencies with the upstream artifacts' (in-degree = 0). A 'propagated vulnerability' in this research context is a vulnerability that reaches an artifact through its dependency chain. An artifact with no dependencies has no dependency chain through which an upstream vulnerability could propagate to it, so the count of propagated vulnerabilities is zero for every member of the independent group by construction. The abstract reports 'zero propagated vulnerabilities' as an empirical advantage discovered by the comparison, but this number is entailed by the membership predicate used to form the group. The claim is therefore a restatement of the definition, not an empirical result.

full rationale

The paper's central contribution is an empirical comparison of independent and dependent artifacts in Maven Central, and most of the reported metrics (popularity, release frequency, PageRank, out-degree centrality, GitHub maintainability features) are measured from the Goblin dataset and from GitHub repositories, not derived from the definition of independence. No load-bearing self-citation chain is present: the paper cites prior work on npm trivial packages only as motivation, and the Goblin dataset is an external resource. The one genuine circular step is the 'zero propagated vulnerabilities' result. Since independent artifacts are defined as having no dependencies, and propagated vulnerabilities are vulnerabilities inherited through dependencies, the zero value is logically forced by the group definition and cannot be claimed as an empirical finding. This does not invalidate the whole study, but it does remove one of the three headline advantages listed in the abstract. The remaining 'fewer vulnerabilities' claim is not circular, but it is statistically fragile: Table I reports 22,081 active independent artifacts versus 267,640 active dependent artifacts, while Table II reports 60 versus 179 CVEs for the last release. Normalizing per artifact yields a higher CVE rate for independent artifacts, so the raw-count comparison may not support the safety recommendation. That is a validity concern rather than a circularity concern under the given rubric. Overall, one definition-level reduction in a headline sub-claim warrants a partial-circularity score of 6.

Assumptions & free parameters 0 free parameters · 4 assumptions · 0 invented entities

The paper's central claims rest on uncritical acceptance of the Goblin dataset and NVD CVE data, plus an ambiguous definition of 'independent' that switches between in-degree and out-degree. No free parameters are fitted.

assumptions (4)

domain assumption The Goblin dataset accurately represents the Maven Central dependency graph and artifact metadata.
All classification and centrality analysis in Section II and III depends on this dataset being complete and correct.
domain assumption CVE and CWE records joined from NVD metadata are complete and correctly associated with artifact releases.
Vulnerability comparisons in Section III-C rely on this join.
ad hoc to paper The 'independent' classification (in-degree = 0) is equivalent to artifacts having no dependencies on other artifacts.
Section II defines independent as in-degree = 0, but the prose and discussion treat it as no outgoing dependencies; this ambiguity is load-bearing for all findings.
domain assumption Popularity as provided by the Goblin dataset (Popularity Past Yr.) is a meaningful proxy for adoption.
Used in RQ3 comparison; no external validation is provided.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Dependency Dilemmas: A Comparative Study of Independent and Dependent Artifacts in Maven Central Ecosystem." pith.science (2026). https://pith.science/paper/P54FHXNJ

@misc{pith2026250412261,
  author       = {Pith},
  title        = {Pith review of: Dependency Dilemmas: A Comparative Study of Independent and Dependent Artifacts in Maven Central Ecosystem},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/P54FHXNJ}},
  note         = {Machine review of arXiv:2504.12261}
}

read the original abstract

The Maven Central ecosystem forms the backbone of Java dependency management, hosting artifacts that vary significantly in their adoption, security, and ecosystem roles. Artifact reuse is fundamental in software development, with ecosystems like Maven Central facilitating this process. However, prior studies predominantly analyzed popular artifacts with numerous dependencies, leaving those without incoming dependencies (independent artifacts) unexplored. In this study, we analyzed 658,078 artifacts, of which 635,003 had at least one release. Among these, 93,101 artifacts (15.4%) were identified as independent (in-degree = 0), while the rest were classified as dependent. We looked at the impact of separate artifacts using PageRank and out-degree centrality and discovered that they were very important to the ecosystem. Further analysis across 18 different metrics revealed several advantages and comparability of independent artifacts with dependent artifacts: comparable popularity (25.58 vs. 7.30), fewer vulnerabilities (60 CVEs vs. 179 CVEs), and zero propagated vulnerabilities. Based on these results, it seems that independent artifacts make a big difference in the ecosystem and give developers a safe, self-contained alternative to traditional dependencies. These findings suggest that independent artifacts might be a beneficial choice for dependencies but have some maintainability issues. Therefore, developers should carefully incorporate independent artifacts into their projects, and artifact maintainers should prioritize this group of artifacts to mitigate the risk of transitive vulnerability propagation and improve software sustainability.

Figures

Figures reproduced from arXiv: 2504.12261 by the authors.

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

Structural and Connectivity Patterns in the Maven Central Software Dependency Network
cs.SE 2025-08 reject novelty 4.0 of 10

A hub-centric sample of the Maven Central dependency graph shows heavy-tailed degree distributions, a giant weakly connected component, and central roles for JUnit, Hamcrest, Spring, and logging libraries.

Reference graph

Works this paper leans on

16 extracted references · 14 canonical work pages · cited by 1 Pith paper

[1]

What predicts software developers’ productivity?,

E. Murphy-Hill, C. Jaspan, C. Sadowski, D. Shepherd, M. Phillips, C. Winter, A. Knight, E. Smith, and M. Jorde, “What predicts software developers’ productivity?,” IEEE Transactions on Software Engineering, vol. 47, no. 3, pp. 582–594, 2019

work page 2019
[2]

Factors that influence productivity: A checklist,

S. Wagner and E. Murphy-Hill, “Factors that influence productivity: A checklist,” Rethinking productivity in software engineering , pp. 69–84, 2019

work page 2019
[3]

Aroma: Automatic reproduction of maven artifacts,

M. Keshani, T.-G. Velican, G. Bot, and S. Proksch, “Aroma: Automatic reproduction of maven artifacts,” Proc. ACM Softw. Eng. , vol. 1, July 2024

work page 2024
[4]

Effects of reuse on quality, productivity, and economics,

W. C. Lim, “Effects of reuse on quality, productivity, and economics,” IEEE software, vol. 11, no. 5, pp. 23–30, 1994

1994
[5]

Mitigating persistence of open-source vulnerabilities in maven ecosystem,

L. Zhang, C. Liu, S. Chen, Z. Xu, L. Fan, L. Zhao, Y . Zhang, and Y . Liu, “Mitigating persistence of open-source vulnerabilities in maven ecosystem,” in Proc. of the 38th IEEE/ACM International Conference on Automated Software Engineering (ASE) , pp. 191–203, 2023

work page 2023
[6]

Towards better dependency scope settings in maven projects,

H. Yang, L. Chen, Y . Cao, Y . Li, and Y . Zhou, “Towards better dependency scope settings in maven projects,” in Proc. of the 14th Asia- Pacific Symposium on Internetware , pp. 90–100, 2023

work page 2023
[7]

On the effect of transitivity and granularity on vulnerability propagation in the maven ecosystem,

A. M. Mir, M. Keshani, and S. Proksch, “On the effect of transitivity and granularity on vulnerability propagation in the maven ecosystem,” in Proc. of the IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER) , pp. 201–211, 2023

work page 2023
[8]

On the untriviality of trivial packages: An empirical study of npm javascript packages,

M. A. R. Chowdhury, R. Abdalkareem, E. Shihab, and B. Adams, “On the untriviality of trivial packages: An empirical study of npm javascript packages,” IEEE Transactions on Software Engineering , vol. 48, no. 8, pp. 2695–2708, 2022

work page 2022

Show all 16 references

[9]

Why do developers use trivial packages? an empirical case study on npm,

R. Abdalkareem, O. Nourry, S. Wehaibi, S. Mujahid, and E. Shihab, “Why do developers use trivial packages? an empirical case study on npm,” in Proc. of the 11th Joint Meeting on Foundations of Software Engineering, pp. 385–395, 2017

2017
[10]

Pagerank

Wikipedia, “Pagerank.” https://en.wikipedia.org/wiki/PageRank. Ac- cessed: (2024, November 19)

2024
[11]

Centrality and network flow,

S. P. Borgatti, “Centrality and network flow,” Social networks, vol. 27, no. 1, pp. 55–71, 2005

2005
[12]

Dependency dilemmas: Replication package

M. H. Shanto, “Dependency dilemmas: Replication package.” https:// doi.org/10.5281/zenodo.14814191

doi
[13]

Navigating and exploring software dependency graphs using goblin,

D. Jaime, J. El Haddad, and P. Poizat, “Navigating and exploring software dependency graphs using goblin,” in Proc. of the International Conference on Mining Software Repositories (MSR 2025) , 2025

2025
[14]

Nvd cvss calculators

N. V . D. (NVD), “Nvd cvss calculators.” https://nvd.nist.gov/ vuln-metrics/cvss. Accessed: (28 Nov, 2024)

2024
[15]

What is cypher

I. Neo4j, “What is cypher.” https://neo4j.com/docs/getting-started/ cypher/. Accessed: (2024, December 1)

2024
[16]

Cve vs. cwe vulnerability: What’s the difference?

I. Homola, “Cve vs. cwe vulnerability: What’s the difference?.” https: //www.codiga.io/blog/cve-vs-cwe/. Accessed: (2023, Jsnuary 28)

2023

Pith tools

Reviewed August 16, 2026 · model on record in the stance chip above.

[1] [1]

What predicts software developers’ productivity?,

E. Murphy-Hill, C. Jaspan, C. Sadowski, D. Shepherd, M. Phillips, C. Winter, A. Knight, E. Smith, and M. Jorde, “What predicts software developers’ productivity?,” IEEE Transactions on Software Engineering, vol. 47, no. 3, pp. 582–594, 2019

work page 2019

[2] [2]

Factors that influence productivity: A checklist,

S. Wagner and E. Murphy-Hill, “Factors that influence productivity: A checklist,” Rethinking productivity in software engineering , pp. 69–84, 2019

work page 2019

[3] [3]

Aroma: Automatic reproduction of maven artifacts,

M. Keshani, T.-G. Velican, G. Bot, and S. Proksch, “Aroma: Automatic reproduction of maven artifacts,” Proc. ACM Softw. Eng. , vol. 1, July 2024

work page 2024

[4] [4]

Effects of reuse on quality, productivity, and economics,

W. C. Lim, “Effects of reuse on quality, productivity, and economics,” IEEE software, vol. 11, no. 5, pp. 23–30, 1994

1994

[5] [5]

Mitigating persistence of open-source vulnerabilities in maven ecosystem,

L. Zhang, C. Liu, S. Chen, Z. Xu, L. Fan, L. Zhao, Y . Zhang, and Y . Liu, “Mitigating persistence of open-source vulnerabilities in maven ecosystem,” in Proc. of the 38th IEEE/ACM International Conference on Automated Software Engineering (ASE) , pp. 191–203, 2023

work page 2023

[6] [6]

Towards better dependency scope settings in maven projects,

H. Yang, L. Chen, Y . Cao, Y . Li, and Y . Zhou, “Towards better dependency scope settings in maven projects,” in Proc. of the 14th Asia- Pacific Symposium on Internetware , pp. 90–100, 2023

work page 2023

[7] [7]

On the effect of transitivity and granularity on vulnerability propagation in the maven ecosystem,

A. M. Mir, M. Keshani, and S. Proksch, “On the effect of transitivity and granularity on vulnerability propagation in the maven ecosystem,” in Proc. of the IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER) , pp. 201–211, 2023

work page 2023

[8] [8]

On the untriviality of trivial packages: An empirical study of npm javascript packages,

M. A. R. Chowdhury, R. Abdalkareem, E. Shihab, and B. Adams, “On the untriviality of trivial packages: An empirical study of npm javascript packages,” IEEE Transactions on Software Engineering , vol. 48, no. 8, pp. 2695–2708, 2022

work page 2022