Pith. sign in

REVIEW 3 major objections 5 minor 46 references

GitHub Repository Complexity Leads to Diminished Web Archive Availability

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

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

Pith's one-line read Web archives preserve less than 5% of GitHub source files, and availability drops sharply with directory depth.

desk verdict Useful depth-resolved measurement of how little GitHub source code survives in the Wayback Machine, but the causal title outruns the evidence. read the letter →

arxiv 2505.15042 v1 pith:O224SEDX submitted 2025-05-21 cs.DL cs.IRcs.SE

David Calano , Michele C. Weigle , Michael L. Nelson This is my paper · ORCID
classification cs.DLcs.IRcs.SE
keywords WebarchivingGitHubrepositoriesDigitalpreservationWaybackMachineMementoCrawlerbehaviorSourcecode
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

This paper measures how well web-hosted software repositories are preserved in the Internet Archive's Wayback Machine, and finds the preservation is far too incomplete to rebuild a project from its archived pages. Using more than 10,000 archived GitHub repositories (plus GitLab, BitBucket, and Sourceforge samples), the authors compare each repository's live source tree, obtained from the GitHub API, against the set of archived file pages, obtained from the Wayback Machine's index. They report that, on average, less than 5% of a repository's source files have an archived page, that around 65% of sampled repositories have no archived source files at all, and that availability drops off steeply with directory depth. The finding matters because the Wayback Machine is a common last-resort source for recovering software whose original host has disappeared; if the paper is right, that fallback generally fails for source code.

What carries the argument

The central mechanism is the depth-stratified comparison of a live repository's file tree against its archived pages. The authors enumerate every source-file URL in a repository from the GitHub API, query the Wayback Machine's index for archived versions of those URLs, and then stratify the archival rate by the file's distance from the repository root. This depth stratification exposes the pattern that carries the argument: archival availability decays steeply with each additional directory level. A secondary mechanism is the page-damage measurement used on archived home pages, which weights missing page resources (images, stylesheets, scripts) by size and importance to produce a damage score between 0% and 100%.

What would settle it

Take a fresh random sample of GitHub repositories, enumerate every source file via the GitHub API, and for each file query the Wayback Machine's availability API for any snapshot. If the fraction of files with at least one snapshot were substantially higher than the paper's depth-stratified rates, especially at depth two or beyond, the claim would fail. The test is cheap and independent, since it does not rely on the paper's original sample or its index queries.

Watch

Extended reading notes

Core claim

The paper's claim is that the HTML-page representation of a Git repository—one page per source file, with the repository home page linking only to top-level files—interacts badly with the way web archives crawl. The authors find that archived repository home pages are often present and readable, but the source tree is mostly absent: across all sampled GitHub repositories, only about 4.72% of source-file pages were archived, and among repositories with at least one archived source file the average was still only 13.39%. Availability is heavily depth-dependent: files linked directly from a repository's home page are archived at roughly 42% (among repositories with any archive presence), while files one directory deep drop to 6.11% and files two directories deep to 2.44%. They also measure home-page damage with a page-damage metric, finding 31.21% of GitHub home pages have minor damage and 1.43% have major damage, with recent JavaScript-loaded pages on GitLab and BitBucket often not replayable at all. The conclusion is that the archived source tree of a repository is typically too incomplete to be reconstructed.

Load-bearing premise

The measurement assumes the GitHub API's list of source files and the Wayback Machine's index of archived pages both accurately reflect what existed and what was captured; if either is incomplete, the reported archival percentages could be systematically wrong.

Editorial extensions

If this is right

  • A project that disappears from GitHub will usually not have its source code recoverable from the Wayback Machine.
  • Repositories with flat, small trees (especially under about 22 files) are the only ones likely to be fully archived.
  • Researchers citing a GitHub repository cannot treat a Wayback capture of the home page as evidence that the code itself is preserved.
  • Web archives that want to preserve source code need crawlers that deliberately traverse repository trees, or they need to integrate with source-code archives.
  • Linking source files directly from a home page or an external site substantially raises the chance that those files get archived.

Reading between the lines

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

  • The depth-decay pattern likely generalizes beyond GitHub to any site that exposes a hierarchical document tree as per-URL pages, such as documentation sites or package registries; the same crawl-depth bias should apply.
  • Because the sample skews toward popular and trending repositories, the true average archival rate across all of GitHub may be even lower than the reported 4.72%.
  • A testable extension would be to correlate the depth-decay curve with a repository's in-links from external sites; the paper's outlier examples suggest external links and popularity are stronger predictors than file count or structural depth, even though the sampled correlations were weak.
  • A practical design suggestion is that archive crawlers could be given the raw git bundle or archive download rather than the HTML page representation, sidestepping depth entirely.
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.

Referee Report

3 major / 5 minor

Summary. This paper investigates how well Web-hosted Git repositories are preserved in the Internet Archive's Wayback Machine. The authors use a sample of 12,110 repository home pages from GitHub, GitLab, BitBucket, and Sourceforge, applying the Memento Damage tool to quantify missing page resources; they report that 58.22% of archived home pages are undamaged, 29.85% have minor damage, and 1.6% have major damage. For the source-tree analysis on about 10,000 GitHub repositories, they combine the GitHub API's current source tree with Wayback CDX API queries to determine what fraction of source-file HTML pages have a 200-status memento, finding that on average fewer than 5% of source files are archived, about 65% of repositories have no archived source files, and the archival rate falls from about 42% for root-level files (among repositories with at least one archived source file) to about 6% at depth one and about 2% at depth two. The paper concludes that repository complexity, measured by file count and directory depth, leads to diminished web archive availability.

Significance. If the measurements are sound, this is a useful empirical contribution to digital preservation and scholarly reproducibility, quantifying the known intuition that page-per-file repository structures are poorly captured by conventional web crawlers. The paper's strengths include the large corpus, the use of public APIs, and the release of the crawler extension and collection scripts, which make the pipeline replicable. The distinction between presentational-page damage and source-tree completeness is appropriate. However, the title's causal claim is not supported by the paper's own weak correlations, and the source-tree denominator is constructed without temporal alignment between the live repository state and the archived captures, a gap the authors explicitly concede in Section 6. With a time-matched denominator, the headline depth gradient could survive, but it has not yet been demonstrated.

major comments (3)
  1. [Section 4 and Section 6] The denominator for the archival percentage is the repository's current source tree from the GitHub API, while the numerator is any 200-status memento found via CDX over the repository's entire lifetime. Files added to the default branch after the last crawl are counted as 'not archived' even though no crawler had the chance to capture them, and files deleted, renamed, or moved before the study are absent from the denominator. The depth gradient in Figure 9 is exactly what this temporal mismatch could produce if root-level files tend to be older and deeper files were added in recent commits. Section 6 acknowledges that 'temporal coherence' was not addressed, but this is not a peripheral caveat: the central quantitative claims depend on the denominator. The authors should either match the denominator to the capture date (for example, by reconstructing the tree at the memento's datetime using the GitHub API with a commit SHA, or by restricting the denominator to files known to exist before a relevant capture window) or provide a sensitivity analysis showing that the depth gradient is robust to such temporal restriction. The paper should also state how branch names in URI paths were normalized, since a default-branch change from 'master' to 'main' would make many CDX queries miss older captures.
  2. [Section 5.2 and title] The reported correlations are internally inconsistent with the narrative. Section 5.2 gives Spearman's rho = 0.246 for file count and rho = 0.116 for structural depth, both positive, yet the text says 'more complex source trees generally had lower rates of availability' and Figure 9 shows a negative depth gradient. Either the sign is missing, the variable is actually the percentage of files not archived, or the interpretation is wrong; please correct and re-report. Regardless of sign, |rho| <= 0.246 is far too weak to support the title's causal 'leads to' claim, and the p-values only reflect the large sample size. To support causal language, the authors would need an identification strategy that controls for repository age, update recency, popularity, and external in-links, which they discuss qualitatively for outliers such as swift-evolution and Konect-Toolbox. As it stands, a descriptive claim such as 'is associated with' is the most the data support.
  3. [Section 5.2, Figure 9] The depth analysis in Figure 9 is restricted to repositories with at least one archived source file, but the denominator at each depth is not defined. Is it the number of files at that depth in the current live tree, or the number of files at that depth in the archived snapshot? If it is the former, the temporal mismatch in the first major comment applies with extra force. In addition, the 'structural depth' used in the correlation analysis is never defined: is it maximum directory depth, mean depth, or the depth of each individual file? Without this definition, the reported rho = 0.116 cannot be interpreted or reproduced.
minor comments (5)
  1. [Table 1] The BitBucket row does not sum to 100%: Not Archived 90.1% + Undamaged 0.09% + Minor 0.002% + Major 0% leaves about 9.8% of the 610 sampled repositories unaccounted for. The text says only six BitBucket pages archived before 2020 could be fully rendered, so the table needs a clearer breakdown that distinguishes 'not archived', 'archived but not rendered', and 'damaged'.
  2. [Section 4] The URI schema description states that 'type is usually either blob for directories and file for files', but on GitHub the path component is 'tree' for directory pages and 'blob' for file pages. If the implemented crawler uses this description literally, it would query incorrect URLs for GitHub source files.
  3. [Abstract and Section 5.2] The abstract reports a 14.89% archival rate for files linked directly from repository home pages, but Section 5.2 reports 'just over 42%' for repositories with a non-zero amount of archived source files. Please state the denominator for each figure so the two numbers are not confusing.
  4. [Section 5.2] The sentence 'three-quarters of the repositories had less than 15% archived' refers to Figure 7, which is an ECDF for repositories with a non-zero number of archived files. Make this conditional explicit in the text, since the 65% of repositories with zero archived files otherwise makes the sentence ambiguous.
  5. [Section 4 and Section 6] The paper should state the data collection dates and the GitHub API version used, since live repository trees and CDX results change over time and the study's replicability depends on knowing the observation window.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the paper is an empirical measurement whose few self-citations are not load-bearing and whose central claims are checkable against external APIs.

full rationale

The paper's central claims are direct empirical measurements: the fraction of archived repository home pages with damage, and the fraction of source-file pages present in the Wayback Machine, stratified by directory depth. These are computed from three external data sources: the GitHub API (live repository trees), the Wayback Machine CDX API (mementos), and the Memento Damage crawler (page content checks). There is no fitted parameter that is later renamed a prediction, and no equation in which the claimed result is introduced by definition. The repository sample is partly drawn from the authors' prior Extract-URLs dataset ([19]) and the damage metric uses their Memento Damage tool ([41]), but these are independently established artifacts with public URLs and open-source implementations; they are measurement instruments, not premises that entail the conclusion. The citation of the authors' earlier finding that 68.39% of repositories were in Software Heritage ([18]) is motivational context, not evidence for the new home-page or source-tree availability numbers. Section 6 does state a genuine limitation: "One important factor we did not address was that of temporal coherence with regard to the source files themselves." This means the denominator (the current GitHub tree) and the numerator (historical CDX mementos) are not time-aligned, so files added after the last crawl lower the measured percentage and renamed or deleted files are missed. That is a validity threat to the depth-gradient claim, but it is not circularity: the percentage is not constructed to equal an input, and correcting the mismatch would require additional data, not a redefinition of the quantity. The empirical claims are externally reproducible against the live GitHub and CDX APIs, so the paper is self-contained against external benchmarks. No circular step is present.

Assumptions & free parameters 2 free parameters · 3 assumptions · 0 invented entities

The paper introduces no new mathematical parameters or entities. The listed free parameters are analytical thresholds, and the axioms are instrumental assumptions about the archive APIs and sampling. The central percentages depend on these choices.

free parameters (2)
  • major damage threshold = 25%
    Hand-chosen threshold classifying damage as major when Memento Damage reports 25% or above; used to define the 1.6% major damage finding.
  • depth grouping threshold = depths >4 grouped
    Directories beyond depth 4 are grouped due to diminishing sample sizes, affecting the depth drop-off curve.
assumptions (3)
  • domain assumption The Memento Damage tool accurately measures page damage for archived pages.
    The entire damage analysis relies on this tool; Section 4 describes using it to assess page damage.
  • domain assumption The Wayback CDX API and GitHub API together provide a complete record of archived and live source pages.
    Section 4: the authors use these APIs to obtain the original source tree and available mementos; if either is incomplete, percentages are biased.
  • domain assumption The sampled repositories are representative of the broader population of GitHub repositories.
    Section 4: sampling combines previously collected academic-cited repositories with manual searches; the paper does not validate representativeness.

how reviews work

0 comments
Cite this review

Pith. "Pith review of GitHub Repository Complexity Leads to Diminished Web Archive Availability." pith.science (2026). https://pith.science/paper/O224SEDX

@misc{pith2026250515042,
  author       = {Pith},
  title        = {Pith review of: GitHub Repository Complexity Leads to Diminished Web Archive Availability},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/O224SEDX}},
  note         = {Machine review of arXiv:2505.15042}
}
read the original abstract

Software is often developed using versioned controlled software, such as Git, and hosted on centralized Web hosts, such as GitHub and GitLab. These Web hosted software repositories are made available to users in the form of traditional HTML Web pages for each source file and directory, as well as a presentational home page and various descriptive pages. We examined more than 12,000 Web hosted Git repository project home pages, primarily from GitHub, to measure how well their presentational components are preserved in the Internet Archive, as well as the source trees of the collected GitHub repositories to assess the extent to which their source code has been preserved. We found that more than 31% of the archived repository home pages examined exhibited some form of minor page damage and 1.6% exhibited major page damage. We also found that of the source trees analyzed, less than 5% of their source files were archived, on average, with the majority of repositories not having source files saved in the Internet Archive at all. The highest concentration of archived source files available were those linked directly from repositories' home pages at a rate of 14.89% across all available repositories and sharply dropping off at deeper levels of a repository's directory tree.

Figures

Figures reproduced from arXiv: 2505.15042 by the authors.

Figure 1
Figure 1. Breakdown of the differences between the version [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. Screenshot of the GitHub home page for the PhantomJS repository showing the embedded representation of the [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. Cropped screenshots of directory and source file [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗
Figures from the paper (7 more)
Figure 5
Figure 5. Figure 5: Archived GitLab repository page for WhisperFish [PITH_FULL_IMAGE:figures/full_fig_p006_5.png]
Figure 4
Figure 4. Figure 4: Highlights of missing image elements on two [PITH_FULL_IMAGE:figures/full_fig_p006_4.png]
Figure 6
Figure 6. Figure 6: Example of missing and intact shield badges for [PITH_FULL_IMAGE:figures/full_fig_p007_6.png]
Figure 7
Figure 7. Figure 7: ECDF showing the percentage of repositories with [PITH_FULL_IMAGE:figures/full_fig_p007_7.png]
Figure 8
Figure 8. Figure 8: Archival of source code files in relation to the total number of files in each GitHub repository. [PITH_FULL_IMAGE:figures/full_fig_p008_8.png]
Figure 10
Figure 10. Figure 10: URI schema example for Git hosting platforms. [PITH_FULL_IMAGE:figures/full_fig_p009_10.png]
Figure 9
Figure 9. Figure 9: Percentage of source code file pages archived at [PITH_FULL_IMAGE:figures/full_fig_p009_9.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

46 extracted references · 31 canonical work pages

  1. [1]

    Jean-François Abramatic, Roberto Di Cosmo, and Stefano Zacchiroli. 2018. Build- ing the universal archive of source code.Commun. ACM61, 10 (2018), 29–31

    work page 2018

  2. [2]

    Vangelis Banos and Yannis Manolopoulos. 2016. A quantitative approach to evaluate Website Archivability using the CLEAR+ method.International Journal on Digital Libraries17, 2 (2016), 119–141. https://doi.org/10.1007/s00799-015- 0144-4

    work page doi:10.1007/s00799-015- 2016

  3. [4]

    Nelson, and Michele C

    Haley Bragg, Himarsha Jayanetti, Michael L. Nelson, and Michele C. Weigle

  4. [5]

    2016.Scripts in a Frame: A Framework for Archiving Deferred Representations

    Justin Brunelle. 2016.Scripts in a Frame: A Framework for Archiving Deferred Representations. PhD thesis. Old Dominion University, Norfolk, VA. https: //doi.org/10.25777/k8px-z178

    work page doi:10.25777/k8px-z178 2016

  5. [6]

    Weigle, and Michael L

    Justin Brunelle, Mat Kelly, Hany SalahEldeen, Michele C. Weigle, and Michael L. Nelson. 2015. Not All Mementos Are Created Equal: Measuring the Impact of Missing Resources.International Journal of Digital Libraries (IJDL)16, 3-4 (September 2015), 283–301. https://doi.org/10.1007/s00799-015-0150-6

    work page doi:10.1007/s00799-015-0150-6 2015

  6. [7]

    Brunelle, Michele C

    Justin F. Brunelle, Michele C. Weigle, and Michael L. Nelson. 2017. Archival Crawlers and JavaScript: Discover More Stuff but Crawl More Slowly. InPro- ceedings of the ACM/IEEE Joint Conference on Digital Libraries (JCDL). 1–10. https://doi.org/10.1109/JCDL.2017.7991554

    arXiv 2017

  7. [8]

    Moore, and Andrew K

    Garret Christensen, Allan Dafoe, Edward Miguel, Don A. Moore, and Andrew K. Rose. 2019. A study of the impact of data sharing on article citations using journal policies as a natural experiment.PLOS ONE14, 12 (12 2019), 1–13. https://doi.org/10.1371/journal.pone.0225883

    work page doi:10.1371/journal.pone.0225883 2019

  8. [9]

    Ludovic Courtès, Timothy Sample, Simon Tournier, and Stefano Zacchiroli. 2024. Source Code Archiving to the Rescue of Reproducible Deployment. InProceedings of the ACM Conference on Reproducibility and Replicability. ACM, 1–10. https: //doi.org/10.1145/3641525.3663622

    arXiv 2024

Show all 46 references
  1. [10]

    Roberto Di Cosmo. 2020. Archiving and Referencing Source Code with Software Heritage. InProceedings of the International Congress on Mathematical Software (ICMS). Springer International Publishing, 362–373

    2020

  2. [11]

    Roberto Di Cosmo, Morane Gruenpeter, and Stefano Zacchiroli. 2018. Identifiers for Digital Objects: the Case of Software Source Code Preservation. InProceedings of the 15th International Conference on Digital Preservation (iPRES). Boston, United States, 1–9. https://doi.org/10...

    2018 doi

  3. [12]

    Roberto Di Cosmo, Morane Gruenpeter, and Stefano Zacchiroli. 2020. Referencing Source Code Artifacts: A Separate Concern in Software Citation.Computing in Science & Engineering22, 02 (2020), 33–43. https://doi.org/10.1109/MCSE.2019. 2963148

    2020 doi

  4. [13]

    Roberto Di Cosmo and Stefano Zacchiroli. 2017. Software Heritage: Why and How to Preserve Software Source Code. InProceedings of the 14th International Conference on Digital Preservation (iPRES). Kyoto, Japan, 1–10. https://hal.science/ hal-01590958

    2017

  5. [14]

    Roberto Di Cosmo and Stefano Zacchiroli. 2023. The Software Heritage Open Science Ecosystem. InSoftware Ecosystems: Tooling and Analytics, Tom Mens, Coen De Roover, and Anthony Cleve (Eds.). Springer International Publishing, Cham, 33–61. https://doi.org/10.1007/978-3-031-36060-2_2

    2023 doi

  6. [15]

    Chris DiBona. 2015. Bidding farewell to Google Code. https://opensource. googleblog.com/2015/03/farewell-to-google-code.html

    2015

  7. [16]

    Florian Echtler and Maximilian Häußler. 2018. Open Source, Open Science, and the Replication Crisis in HCI. InProceedings of the Extended Abstracts of the 2018 CHI Conference on Human Factors in Computing Systems(Montreal QC, Canada) (CHI EA ’18). Association for Computing Mac...

    2018

  8. [17]

    Weigle, and Michael L

    Emily Escamilla, Talya Cooper, Vicky Rampin, Martin Klein, Michele C. Weigle, and Michael L. Nelson. 2022. The Rise of GitHub in Scholarly Publications. In Proceedings of the Theory and Practice of Digital Libraries Conference (TPDL). https://doi.org/10.1007/978-3-031-16802-4_15

    2022 doi

  9. [18]

    Weigle, and Michael L

    Emily Escamilla, Martin Klein, Talya Cooper, Vicky Rampin, Michele C. Weigle, and Michael L. Nelson. 2023. Cited But Not Archived: Analyzing the Status of Code References in Scholarly Articles. InProceedings of the International Conference on Asia-Pacific Digital Libraries (IC...

    2023 doi

  10. [19]

    Weigle, and Michael L

    Emily Escamilla, Lamia Salsabil, Martin Klein, Jian Wu, Michele C. Weigle, and Michael L. Nelson. 2023. It’s Not Just GitHub: Identifying Data and Software Sources Included in Publications. InProceedings of the Theory and Practice of Digital Libraries Conference (TPDL). 195–20...

    2023 doi

  11. [20]

    Greg Foster. 2024. How GitHub monopolized code hosting. https://graphite. dev/blog/github-monopoly-on-code-hosting

    2024

  12. [21]

    Kritika Garg, Himarsha R Jayanetti, Sawood Alam, Michele C Weigle, and Michael L Nelson. 2024. Challenges in replaying archived Twitter pages.Inter- national Journal on Digital Libraries25, 2 (2024), 217–236. GitHub Repository Complexity Leads to Diminished Web Archive Availability

    2024

  13. [22]

    Packer, and Thanas- sis Tiropanis

    Wilhelm Hasselbring, Leslie Carr, Simon Hettrick, Heather S. Packer, and Thanas- sis Tiropanis. 2019.FAIR and Open Computer Science Research Software. Technical Report arXiv:1908.05986. arXiv. http://arxiv.org/abs/1908.05986

    2019 arXiv

  14. [23]

    Friederike Hendriks, Dorothe Kienhues, and Rainer Bromme. 2020. Replication crisis = trust crisis? The effect of successful vs failed replications on laypeople’s trust in researchers and research.Public Understanding of Science29, 3 (2020), 270–288. https://doi.org/10.1177/096...

    2020 doi

  15. [24]

    Simon Hettrick. 2014. It’s impossible to conduct research without software, say 7 out of 10 UK researchers. https://www.software.ac.uk/blog/its-impossible- conduct-research-without-software-say-7-out-10-uk-researchers

    2014

  16. [25]

    Jones, Herbert Van de Sompel, Harihar Shankar, Martin Klein, Richard Tobin, and Claire Grover

    Shawn M. Jones, Herbert Van de Sompel, Harihar Shankar, Martin Klein, Richard Tobin, and Claire Grover. 2016. Scholarly Context Adrift: Three out of Four URI References Lead to Changed Content.PLOS ONE11, 12 (12 2016), 1–32. https://doi.org/10.1371/journal.pone.0167475

    2016 doi

  17. [26]

    Nelson, and Michele C

    Mat Kelly, Michael L. Nelson, and Michele C. Weigle. 2014. The Archival Acid Test: Evaluating Archive Performance on Advanced HTML and JavaScript. In Proceedings of the ACM/IEEE Joint Conference on Digital Libraries (JCDL). London, 25–28. https://doi.org/10.1109/JCDL.2014.6970146

    2014

  18. [27]

    Johannes Kiesel, Florian Kneist, Milad Alshomary, Benno Stein, Matthias Hagen, and Martin Potthast. 2018. Reproducible Web Corpora: Interactive Archiving with Automatic Quality Assessment.Journal of Data and Information Quality10, 4, Article 17 (Oct 2018), 25 pages. https://do...

    2018 doi

  19. [28]

    Martin Klein, Herbert Van de Sompel, Robert Sanderson, Harihar Shankar, Lyud- mila Balakireva, Ke Zhou, and Richard Tobin. 2014. Scholarly Context Not Found: One in Five Articles Suffers from Reference Rot.PLOS ONE9, 12 (12 2014), 1–39. https://doi.org/10.1371/journal.pone.0115253

    2014 doi

  20. [29]

    Petros Maniatis, Mema Roussopoulos, T. J. Giuli, David S. H. Rosenthal, and Mary Baker. 2005. The LOCKSS peer-to-peer digital preservation system.ACM Transactions on Computer Systems23, 1 (Feb. 2005), 2–50. https://doi.org/10. 1145/1047915.1047917

    2005

  21. [30]

    Vadim Markovtsev and Waren Long. 2018. Public Git archive: A big code dataset for all. InProceedings of the 15th International Conference on Mining Software Repositories(Gothenburg, Sweden)(MSR ’18). Association for Computing Ma- chinery, New York, NY, USA, 34–37. https://doi....

    2018

  22. [31]

    Corren McCoy. 2017. Pagination Considered Harmful to Archiving. https://ws- dl.blogspot.com/2017/09/2017-09-13-pagination-considered.html

    2017

  23. [32]

    Genevieve Milliken. 2021. IASGE Environmental Scan. https://osf.io/ku24q/

    2021

  24. [33]

    Sarah Nguyen. 2021. Gap Analysis of the Scholarly Git Experience. https: //osf.io/q27m9/

    2021

  25. [34]

    Sarah Nguyen and Vicky Rampin. 2022. Who Writes Scholarly Code?. InPro- ceedings of International Digital Curation Conference (IDCC). https://doi.org/10. 5281/zenodo.6670225

    2022

  26. [35]

    2021.Organizing the graph of public software development for large-scale mining

    Antoine Pietri. 2021.Organizing the graph of public software development for large-scale mining. Theses. Université Paris Cité. https://hal.science/tel-03515795

    2021

  27. [36]

    Antoine Pietri, Diomidis Spinellis, and Stefano Zacchiroli. 2020. The Software Heritage Graph Dataset: Large-scale Analysis of Public Software Development History. InProceedings of the 17th International Conference on Mining Software Repositories(Seoul, Republic of Korea)(MSR ...

    2020

  28. [37]

    Victoria Reich. 2008. CLOCKSS—It Takes a Community.The Serials Librarian54, 1-2 (2008), 135–139. https://doi.org/10.1080/03615260801973968

    2008 doi

  29. [38]

    Ingram, Ed- ward A

    Lamia Salsabil, Jian Wu, Muntabir Hasan Choudhury, William A. Ingram, Ed- ward A. Fox, Sarah M. Rajtmajer, and C. Lee Giles. 2022. A Study of Computa- tional Reproducibility using URLs Linking to Open Access Datasets and Software. InCompanion Proceedings of the Web Conference(...

    2022

  30. [39]

    Franklin Sayre and Amy Riegelman. 2018. The Reproducibility Crisis and Academic Libraries.College & Research Libraries79, 1 (2018), 2. https: //doi.org/10.5860/crl.79.1.2

    2018 doi

  31. [40]

    Len Shustek. 2006. What Should We Collect to Preserve the History of Software? IEEE Annals of the History of Computing28, 4 (2006), 112–111. https://doi.org/ 10.1109/MAHC.2006.78

    2006 doi

  32. [41]

    Erika Siregar. 2017. Deploying the Memento-Damage Service. https://ws- dl.blogspot.com/2017/11/2017-11-22-deploying-memento-damage.html

    2017

  33. [42]

    Vicky Steeves, Genevieve Milliken, and Sarah Nguyen. 2020. Let’s Talk Git! Investigating and Archiving the Scholarly Git Experience. InProceedings of code4Lib 2020. Pittsburgh, Pennsylvania, USA

    2020

  34. [43]

    Vicky Steeves, Genevieve Milliken, Sarah Nguyen, Wendy Hagenmaier, Euan Cochrane, Alexandra Chassanoff, and Morane Gruenpeter. 2020. Saving Software for Future [Re]use. InProceedings of Archives*Records, the Annual Meeting of the Society of American Archivists (SAA)

    2020

  35. [44]

    Vicky Steeves and Sarah Nguyen. 2020. commit-ment issues with Git: investigat- ing & archiving y’alls work. InProceedings of csv,conf,v5

    2020

  36. [45]

    Herbert Van de Sompel, Michael Nelson, and Robert Sanderson. 2013. HTTP Framework for Time-Based Access to Resource States – Memento. RFC 7089. https://doi.org/10.17487/RFC7089

    2013 doi

  37. [46]

    Supatsara Wattanakriengkrai, Bodin Chinthanet, Hideaki Hata, Raula Gaikovina Kula, Christoph Treude, Jin Guo, and Kenichi Matsumoto. 2022. GitHub reposi- tories with links to academic papers: Public access, traceability, and evolution. Journal of Systems and Software183 (2022)...

    2022

  38. [47]

    Weigle, Michael L

    Michele C. Weigle, Michael L. Nelson, Sawood Alam, and Mark Graham. 2023. Right HTML, Wrong JSON: Challenges in Replaying Archived Webpages Built with Client-Side Rendering. InProceedings of ACM/IEEE Joint Conference on Digital Libraries (JCDL). 82–92. https://doi.org/10.1109/...

    2023

Pith tools

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