arXiv subjects

Audris Mockus

Publications and source records attributed to Audris Mockus.

At least 19 recordsLinked to original sources

arXiv2026

The Ground Is Shifting: A Reflection on the Foundations of Software Measurement

For most of the past six decades, software measurement relied on labor-intensive manual collection of proprietary data, which hampered progress. The shift to repurposing traces from version control and related tools dramatically expanded data availability$\unicode{x2014}$especially with the rise of open-source software$\unicode{x2014}$but hinged on an often unstated assumption: that these tools are used by professional developers to build genuine software systems. However, as trace-generating tools, data types and scale, and empirical methods have all evolved, it has become clear that changes in data generation and analytical approaches affect many prior findings about software development, maintenance, and evolution. With AI agents now actively using these same tools, the resulting traces frequently violate the original assumption of human origin. To preserve the relevance of software measurement research, immediate action is needed: We must detect when foundational assumptions are violated in contemporary data and develop new methodologies that remain valid under changed circumstances. To this end, we propose a systematic AI-assisted replication program that revisits key findings using modern techniques, aiming for methods that yield consistent results on current data to keep software measurement meaningful.

cs.SE↗

arXiv2026

Scaling Author Identity Disambiguation to the World of Code: A Methodology

We describe the methodology used to alias the free-text author/committer identities of the entire World of Code (WoC) collection (version V2604, ~107M distinct author strings over ~6B commits) into canonical persons, extending the fingerprint-based anti-aliasing of ALFAA and the 38M-identity resolution of Fry et al. by an order of magnitude. At this scale the central problem is over-merge, not missed merges: a few bridge identities (bots, role accounts, placeholder emails, multi-author commit fields) transitively weld unrelated clusters through the global union step into million-member "mega-clusters." We report the full experimental record (more than twenty experiments, including unsuccessful ones) behind the deployed design. Node-level gates (information score, project spread, degree) preserve recall but cannot dissolve the mega-cluster; per-value blocklists of high-quality-but-shared attributes are recall-safe but cannot break a redundant mesh; the working composition is a betweenness cut over the exact union graph plus a per-edge classifier trained on 2.6M labels mined from GitHub no-reply identifiers. That classifier, filtering dormant cross-project shingle groups and joined by GitHub's own account assertions, then recovers the recall the precision work had foregone. Against human-adjudicated pairs the per-edge model transfers at AUC 0.99; end to end the largest cluster falls from 170,431 (and a predecessor's 3.0M) to under 7,000 w hile gold recall rises from 0.44 to 0.70 at increasing precision, and on an independent 21M-alias GitHub ground truth the final map outscores its predecessors and the published state of the art among global, privacy-preserving resolvers. The record doubles as a catalog of scale lessons: structural cuts do not transfer to edge sets they never saw, and recall-only and precision-only benchmarks invert verdicts unless read together.

cs.SE↗

arXiv2026

A Global Author-Identity Map for the World of Code:62.7M Developer Identities from 106.8M Author Strings over 5.87B Commits

Mining software repositories at global scale founders on author identity: the same developer commits under many name/email strings, and the same string is reused by many developers. We release a curated author-identity map for World of Code (WoC) version V2604, covering all 5,866,595,698 commits. It ships four co-versioned artifacts: a global alias map (a2AFullSUG) folding 106,826,059 raw author/committer strings into canonical identities; a per-identity classification (A2clsFull) tagging each id good, bad-by-attribute, local, bot, or partial; a within-project table (P2aAFull) recovering low-quality ids inside the one project where their reuse is unambiguous; and a commit-to-identity table (c2AFull) tagging every commit with its resolution provenance. The map is mega-cluster free, its largest cluster 6,910 ids (one GitHub noreply identity), and it resolves 73.5% of six billion commits into multi-id identities, raising human-id commit coverage to 98.17%. The design problem is clumping, not recall: a naive transitive union over shared-attribute edges welds three million unrelated people into one cluster, an over-merge that recall-only benchmarks price at zero. We report both error families, splitting and clumping, and show the high precision claimed by global-scale union maps can be an artifact of never measuring the conflated region. Against the ALFAA human-rated gold set the map scores recall 0.70 / precision 0.88, where the prior WoC map's apparent 0.95 precision collapses to 0.52 once its 3,006,318-id mega-cluster is counted. A canonical software-author identity is also a cross-corpus join key to scholarly author graphs, where clumping is again the binding constraint. All artifacts ship with the WoC V2604 release and a self-contained replication package.

cs.SE↗

arXiv2026

Claimed or Attested? A Commit-Signature Dataset and Identity Trust Tiers across the World of Code

An author string in a git commit is free text the committer typed, so identity resolution over a global commit corpus rests on a claim that nothing in the commit verifies. A cryptographically signed commit is different: it binds the commit to a key the committer controls, and when that key ties back to a real-world identity the git identity becomes attested rather than merely claimed. We release the first commit-signature axis for the World of Code (WoC), extracted for the V2604 collection. The signature travels in the commit object's gpgsig header and is already carried, unparsed, in the commit-message field of the WoC commit tables, so the axis is a scan over existing tables rather than a re-read of the object database. Over the V2604 corpus of 5,866,595,698 commits, 17.59% carry a signature (PGP dominant at 98.96%, with a growing minority of SSH and X.509/sigstore signatures), or 1,031,721,316 signed commits. We release the per-commit signature map c2sigFull, a key-to-author graph gated so that shared organization and continuous-integration keys are separated from person keys, and A2trust, a per-identity attestation tier (unsigned, signed, real-world-bound, cross-corpus attested) that extends the published A2cls identity-class dataset. The signature axis is a precision anchor, not a coverage layer: signed commits skew toward recent and security-conscious developers, a population that overlaps the scholarly authors a bibliography join targets. We use the person keys to build a cryptographically grounded alias gold that calibrates the heuristic WoC alias map independently of hand-labeled pairs, and to attach an attestation provenance to science-to-software identity links. All artifacts are released as a self-contained, in dependently hosted replication package keyed to the WoC V2604 collection.

cs.CR↗

arXiv2026

File-Level Copying Is an Implicit Dependency in Open Source

File-level copying is a widespread but ungoverned form of software reuse. Copying files across repositories reduces supply-chain visibility: it removes the four observable signals a package manager provides for a declared dependency (provenance, maintenance, security, and compliance) with no mechanism to restore them. To characterize the scale and consequences of this unmanaged reuse, we present a mixed-method study of copying across the entire open-source ecosystem using World of Code (WoC). From a 0.1% commit sample, we extract 690,500 copy events and retain 3,912 rationale-bearing copy commits for intent labeling. We show that the 13 axial copy forms, spanning vendored dependencies, hardware/driver synchronization, scaffolding, UI assets, and direct source-code reuse, are unreliable proxies for developer intent: among rationale-bearing commits, hardware/driver copies are predominantly fork-maintenance work (78%), while dependency-vendoring copies more often signal upstream bypass (70%) than offline availability. These visibility gaps are form-specific: security and license risk concentrate in complementary copy forms. Copied sources are frequently stale (median 155 days; 38.5% over one year old) and seldom record a recoverable origin (4.3% documented), let alone a checkable version (2.0% versioned); even vendored copies record where they came from only 10% of the time. Security risk concentrates in vendored dependencies: 17,314 CVE-risk copy commits in the full-WoC graph, 88% in the dependency-vendoring form; 80% score CVSS >= 7.0 and upstream-fix adoption is only 47%-84%. License risk concentrates in direct source-code reuse: 41,777 pre-validation candidates, 66% in the source-code form, with 39 verified high-star violations (kappa = 0.752). Both risks reach packaged software and are invisible to dependency scanners operating on declared metadata alone.

cs.SE↗

arXiv2026

Was It Never Collected, or Rewritten Away? A Commit-Provenance Dataset Separating Ingestion Gaps from Upstream History Edits across the World of Code

Any global mirror of open-source version control is incomplete, but the reasons a commit is missing are not interchangeable: a project may have force-pushed it away (so it no longer exists upstream), or the mirror may never have ingested it (a true collection gap). We release a commit-provenance dataset that separates these cases at scale by comparing two views of the same commit graph: the GHArchive event stream, a historical witness of what GitHub advertised at push time, and the World of Code (WoC) V2604 object database, an accumulated union of periodic fetches that never deletes a collected commit. Walking each reference's PushEvent chain reconstructs force-pushes structurally (a before that is not the prior head breaks the fast-forward chain; no recorded flag exists across eras), and joining every advertised commit against WoC membership yields a three-way label. Over 1,118,116,350 advertised commits, 53.35% are present in WoC, 6.47% are rewritten (orphaned by a later force-push, an upstream edit and a correct absence), and 40.18% are never-ingested (the candidate collection gap). About one missing-commit case in fifteen is a rewrite the project erased, not a mirror gap. We release the force-push witness (166,710,831 events over 19,926,250 repositories) and a per-project rollup (78,125,788 repositories; force-pushing observed in 25.47%, a rewritten commit in 12.85%). We treat the 40% never-ingested share as an upper bound on the collection gap and state five reasons it overcounts. The dataset makes mirror-completeness reporting honest, flags rewritten commits as duplicate patch sources for contribution counting, and corrects a 10.82% corpus-wide undercount that history editing imposes on commit-based productivity, with a released per-project correction factor. All artifacts ship as a self-contained, independently hosted replication package keyed to WoC V2604.

cs.SE↗

arXiv2026

A Preliminary Study on Explaining Risk of Code Changes using LLM-Based Prediction Models

Predictions by machine learning (ML) and artificial intelligence (AI) models are often received skeptically unless they are paired with intelligible explanations. In the context of just-in-time defect prediction, highlighting small portions of a software change (diff) -- beyond rule-based lints -- where risk may be concentrated has not yet been extensively investigated. In this work, we leverage attention weights from an LLM-based Diff Risk Score (DRS) model to highlight parts of a diff that the model focuses on when predicting risk. We aggregate token-level attention into interpretable code units (lines, hunks, and files), and present the top-K units to developers as a lightweight form of guidance during code review. We evaluate our approach using expert-labeled changes that have caused real outages. Results show that the highlighted snippets cover expert-labeled outage-causing change lines 53.85% of the time when highlighting the top-2 hunks, while requiring developers to review 26.28% of the changed lines on average. Because attention is produced during standard model inference, the approach is scalable for large development workflows and can be surfaced in the code review UI with low additional latency.

cs.SE↗

arXiv2026

Deforking the World of Code: A Project-Provenance Map that Recovers Cross-Forge Fork Families that Platform Graphs Cannot See

Forks share git history, so a commit surfaces in many repositories and any spread- or popularity-based measure over raw repositories is inflated by orders of magnitude. We release a curated deforking map for the World of Code (WoC) version V2604: p2PFull, which collapses every raw repository p into the deforked project P to which it belongs, built from the global shared-commit relation (51.79M shared-commit groups) via a hub-node star encoding and parallel Louvain clustering, plus capped variants (cap250/cap500) that bound mega-cluster size. The naive shared-history union over-merges: the project graph welds unrelated software into giant clusters (largest uncapped cluster 443,010 repositories, bridged by shared-commit groups as large as 267,200), for the same structural reason author-identity graphs do. A cheap size cap removes the boilerplate-hub bridges; a structural-bridge diagnostic, the cut that dissolved the analogous author mega-cluster, run here but deliberately not applied, shows the post-cap residual is genuine vendored history, robust to the cut, so we leave it intact. We validate the map against GitHub's declared fork graph reconstructed from GHArchive ForkEvents, finding 99.01% edge agreement conditional on both repositories being in WoC. Disagreements fall into two classes: a completeness byproduct (edges GitHub asserts but WoC has not ingested) and the central contribution, WoC-only fork families that GitHub's platform graph cannot represent, including 5.53% multi-forge families and 1.54% whose fork root is not on GitHub. We additionally release a refreshed fork-exclusion list (134.1M children, 3.4x the GHTorrent-era 39.5M) and a detached-fork inventory (455,550 hard-detached edges; 240,441 genuine independent origins). All artifacts are a self-contained, independently hosted replication package keyed to the WoC V2604 collection.

cs.SE↗

arXiv2026

The Reciprocal Impact of Science and Software: A Cross-Corpus Analysis of How Research Shapes Software and Software Enables Research

Software and scientific knowledge co-evolve, yet they are catalogued in separate corpora that rarely speak to one another. We bridge them at global scale by linking World of Code (a near-complete mirror of public version-control history) to Semantic Scholar and OpenAlex through a typed cross-corpus graph of 69.8M edges over eight relation types (paper-to-software mentions, software-to-paper citations, software dependencies, authorship, affiliation, and identity bridges). Anchoring on 18,247 curated science repositories, we ask two reciprocal questions: what is the impact of science on software, and of software on science? To test whether this Science-Software Supply Chain (S3C) view is feasible, we run basic investigations rather than claim a definitive measurement. The two directions appear to illuminate different, complementary strata: the literature's reach into software is dominated by a reproducibility and packaging layer (nf-core, Nextflow, Bioconda) and sequence-analysis tools, whereas software's reach back into science is proxied by a largely invisible machine-learning and data-science infrastructure tier (PyTorch, seaborn, NLTK). The direct paper-names-software channel is too sparse to rank: a human-curated gold benchmark links none of its 65 in-scope cases. Dependency reuse stands in as a proxy and is at most weakly coupled to citation count and to stars (Spearman rho=0.36). Our most cautionary finding is about measurement itself: the reuse-citation coupling flips sign and confidence across two reasonable ways of pairing a repository with a citation count, through papers that name it (n=137, rho=0.05, CI straddling zero) versus DOIs a repository declares for itself (n=1,067, rho=0.13, CI [0.07,0.19]). With linkage this sparse, the sign of a headline correlation depends on which gap one tolerates, so we report both and refrain from a strong decoupling claim.

cs.DL↗

arXiv2026

Detecting AI Coding Agents in Open Source: A Validated Multi-Method Census of 180 Million Repositories

Generative AI coding agents are entering the open-source supply chain, yet their diverse and often invisible traces leave their prevalence poorly understood. We introduce a multi-layered detection framework that integrates configuration-file scanning, commit-message analysis, author-identity matching, and bot-signature lookup across World of Code (180M+ Git repositories), classifying agent traces into four behavioral types. No single method captures more than a fraction of activity: multi-method detection identifies 850,157 Claude Code commits in one snapshot, of which bot-account lookup_the signal most adoption studies rely on_recovers only 28,154 (3.3%), a 30x relative-recall gap, so single-signal prevalence estimates are biased low by at least this factor. Every detection pattern is hand-validated (495 labels) with per-cell precision and Wilson confidence intervals. Across snapshots from December 2024 to April 2026, commit-attributed agents generate over 320,000 commits per month; Claude Code leads (886,122 commits across 17,295 projects) and dominates silent, configuration-file-only adoption (21,078 projects). Compared against an independent pull-request census (AIDev), the two channels capture nearly disjoint agent populations_a PR census misses 79% of commit-detected Claude Code adopters and essentially all Codex adopters_and different kinds of work: PR-deployed cloud agents (Codex, Cursor) surface as feature work, while commit-deployed in-editor agents (Claude Code, OpenHands, Aider) surface as maintenance. The observed work profile follows deployment and detection mode rather than the tool itself, so no single channel is representative.

cs.SE↗

arXiv2026

The Prevalence and Impact of Licenses in Open Software Projects

The terms of how publicly available source code can be used are dictated by its license. The license (or its absence), in turn, affects what code the project may reuse and how its code can be (re)used and may also affect external participation and overall activity of the project. We aim to better understand the general state of license distribution overall and within language ecosystems and to investigate if license changes are associated with a noticeable variations of project output. To accomplish that we identify licenses and license types for over 100M software projects and find that most do not contain any license, that permissive licenses represent the bulk of most licenses, and that permissive licensing is representing an increasing proportion of all licenses over time. Restrictive licenses are more likely to be retained, however. There is a great variation among language ecosystems with C-language strongly favoring restrictive licenses. The analysis of license change impact comparing activity within one year of the adoption of the initial and final licenses shows that the change from restrictive to permissive license varies with the ecosystem. C-language ecosystems show reduced activity while Python shows increased activity when comparing restrictive to permissive license transition. Our results demonstrate dramatic changes in license type prevalence over time and find that the effects of license changes may have opposite effects depending on the language ecosystem.

cs.SE↗

arXiv2026

Ensuring Open Source Integrity: The Intersection of Copy-Based Reuse and License Compliance

As other creative work, source code is protected by copyright. The owner can license the work, e.g., to permit copy and other kinds of use, and even start legal proceeding against license violators. However, source code can be reused in subtle ways, e.g., via copying without explicit package manager dependencies, making it hard to reason about potential license noncompliance. Using the World of Code infrastructure approximating the entirety of open source software, in this paper we create a copy-based code reuse network mapping direct copying across projects, and use it to quantify the extent of potential license noncompliance across the entire open source ecosystem. In addition, we estimate regression models to understand whether code copying is affected by the origin project's license, and, if so, how it varies with other project characteristics. We find that code in repositories with permissive licenses, such as MIT and Apache, shows higher likelihood of reuse across programming languages. In contrast, copyleft licenses, like the GPL, exhibit mixed effects. Public domain licenses, despite their aim of allowing unrestricted use, are associated with lower likelihood of copy-based reuse. A widespread potential license noncompliance appears to accompany copy-based reuse, with 39.4% of project combinations at potential noncompliance risk, particularly when licenses are unclear or absent. Our findings reveal that only 2.43% of reuse detected through the copy-based network was discoverable via dependency analysis, highlighting the limitations of existing dependency-tracking tools in capturing copy-based reuse.

cs.SE↗

arXiv2026

Beyond the Grave: An Empirical Study of Dormancy and Revival in Scientific Open-Source Software

Background. Inactivity thresholds classify scientific open-source software (OSS) as abandoned but cannot distinguish permanent abandonment from temporary dormancy; moving the cutoff from 1 to 36 months changes the abandoned count in the SciCat corpus from 18,030 to 8,010. Aims. We characterize dormancy causes, revival mechanisms, recovery durability, and lifecycle archetypes in dormant-revived scientific OSS. Method. From 18,247 SciCat repositories we identify 2,984 dormant-revived candidates and field-code a stratified sample of 750 projects with 75 analyst-coders under a two-phase adjudication protocol (post-adjudication kappa 0.779-0.857). A rule-based classifier produces five dimensions: dormancy cause (T1), revival mechanism (T2), nature of revival work (T3), revival sustainability (T4), and lifecycle archetype (T5). Results. Dormancy cause is unresolvable from repository evidence for 52.5% of projects; among resolvable cases, feature/milestone freeze outnumbers research-output completion 5.4:1. Non-sustained recovery outnumbers sustained 2.14:1; 11.5% of apparent revivals are bot-only or single-spike artifacts. Lifecycle archetype is more strongly associated with sustainability than revival mechanism or work type (medium effect on the structurally-independent subset). Conclusions. A fixed inactivity threshold is insufficient to reliably classify scientific OSS abandonment. Gap duration, lifecycle archetype, and contributor continuity together provide more discriminating information than any single threshold.

cs.SE↗

arXiv2026

Automating Low-Risk Code Review at Meta: RADAR, Risk Calibration, and Review Efficiency

AI-assisted coding tools have altered software production. At Meta, significant lines of code per human-landed diff grew by 105.9% year over year and per-developer diff volume rose 51%, with agentic AI responsible for over 80% of that growth. Meanwhile, the share of diffs receiving timely review has declined, exposing a widening gap between code supply and reviewer bandwidth. We ask three questions that progress from feasibility through calibration to impact: (1) can risk-stratified automation operate at scale across diverse organizations, (2) how does tuning the risk threshold affect the trade-off between automation yield and safety, and (3) to what extent does automated review reduce end-to-end latency for AI-generated changes? We deployed RADAR (Risk Aware Diff Auto Review), a multi-stage funnel that classifies each diff by authorship and source type, applies eligibility gates, static heuristics, a machine-learned Diff Risk Score, LLM-based Automated Code Review, and deterministic validation before landing qualifying changes. We evaluate RADAR through telemetry covering 535K+ RADAR-reviewed diffs, observational before-after comparisons for policy changes, and difference-in-differences analysis of efficiency outcomes. RADAR has reviewed 535K+ diffs and landed 331K+. Relaxing the Diff Risk Score threshold from the 25th to the 50th percentile increased the approve rate to 60.31%. The revert rate for RADAR-reviewed diffs is 1/3 that of non-RADAR diffs, and the Production Incident rate is 1/50 that of non-RADAR diffs. RADAR reduces median time to close by over 330% and median diff review wall time by 35%. Risk-aware layered automation can materially reduce review bottlenecks created by AI-driven code growth without compromising production safety.

cs.SE↗

arXiv2026

Accountability in Open Source Software Ecosystems: Workshop Report

Open source software ecosystems are composed of a variety of stakeholders including but not limited to non-profit organizations, volunteer contributors, users, and corporations. The needs and motivations of these stakeholders are often diverse, unknown, and sometimes even conflicting given the engagement and investment of both volunteers and corporate actors. Given this, it is not clear how open source communities identify and engage with their stakeholders, understand their needs, and hold themselves accountable to those needs. We convened 24 expert scholars and practitioners studying and working with open source software communities for an exploratory workshop discussion on these ideas. The workshop titled "Accountability and Open Source Software Ecosystems" was organized on Oct 14-15 on campus in Carnegie Mellon University, Pittsburgh, PA. The purpose of this in-person workshop was to initiate conversations that explore important and urgent questions related to the role of accountability in open source software ecosystems, and to inspire an exciting research agenda and meaningful stakeholder engagement ideas for practitioners.

cs.SE↗

arXiv2025

DRS-OSS: A Diff-Risk Scoring Tool for Continuous Integration Workflows

Software teams need change-risk scores that can guide continuous integration decisions such as review prioritization, test scheduling, and downstream validation before risky changes are merged or released. However, open-source teams often lack deployable tools for surfacing these risk signals in everyday CI workflows. We present DRS-OSS, an open-source diff-risk scoring tool for continuous integration workflows. DRS-OSS is designed as a deployable and customizable pipeline rather than as a standalone prediction model. It combines a REST API gateway, containerized model services, a developer dashboard, GitHub integration, and a replication package that lets users retrain or replace the backend with other transformer models. The bundled workflow combines commit messages, commit diffs, and change metrics in a single risk-prediction pipeline. The default packaged backend uses a Llama 3.1 8B sequence classifier configured for long diffs. Its training recipe uses parameter-efficient tuning, quantization, CPU offloading, and customization helper scripts so that it can be adapted on modest hardware. We compare DRS-OSS with similar tools and evaluate the bundled classifier on ApacheJIT, where it reaches an ROC-AUC of 0.895 and outperforms prior baselines. From a user-feedback perspective, DRS-OSS has received interest from Uber, Duolingo, and Microsoft in adapting the workflow to their own continuous integration settings. The full tool is released with source code, customization scripts, deployment artifacts, a public repository, a live demo at worldofcode.org/drs, and a demonstration video at youtube.com/watch?v=2FzeRRdNaco.

cs.SE↗

arXiv2025

Scientific Open-Source Software Is Less Likely to Become Abandoned Than One Might Think! Lessons from Curating a Catalog of Maintained Scientific Software

Scientific software is essential to scientific innovation and in many ways it is distinct from other types of software. Abandoned (or unmaintained), buggy, and hard to use software, a perception often associated with scientific software can hinder scientific progress, yet, in contrast to other types of software, its longevity is poorly understood. Existing data curation efforts are fragmented by science domain and/or are small in scale and lack key attributes. We use large language models to classify public software repositories in World of Code into distinct scientific domains and layers of the software stack, curating a large and diverse collection of over 18,000 scientific software projects. Using this data, we estimate survival models to understand how the domain, infrastructural layer, and other attributes of scientific software affect its longevity. We further obtain a matched sample of non-scientific software repositories and investigate the differences. We find that infrastructural layers, downstream dependencies, mentions of publications, and participants from government are associated with a longer lifespan, while newer projects with participants from academia had shorter lifespan. Against common expectations, scientific projects have a longer lifetime than matched non-scientific open-source software projects. We expect our curated attribute-rich collection to support future research on scientific software and provide insights that may help extend longevity of both scientific and other projects.

cs.SE↗

arXiv2025

Code Improvement Practices at Meta

The focus on rapid software delivery inevitably results in the accumulation of technical debt, which, in turn, affects quality and slows future development. Yet, companies with a long history of rapid delivery exist. Our primary aim is to discover how such companies manage to keep their codebases maintainable. Method: we investigate Meta's practices by collaborating with engineers on code quality and by analyzing rich source code change history to reveal a range of practices used for continual improvement of the codebase. In addition, we replicate several aspects of previous industry cases studies investigating the impact of code reengineering. Results: Code improvements at Meta range from completely organic grass-roots done at the initiative of individual engineers, to regularly blocked time and engagement via gamification of Better Engineering (BE) work, to major explicit initiatives aimed at reengineering the complex parts of the codebase or deleting accumulations of dead code. Over 14% of changes are explicitly devoted to code improvement and the developers are given ``badges'' to acknowledge the type of work and the amount of effort. Our investigation to prioritize which parts of the codebase to improve lead to the development of metrics to guide this decision making. Our analysis of the impact of reengineering activities revealed substantial improvements in quality and speed as well as a reduction in code complexity. Overall, such continual improvement is an effective way to develop software with rapid releases, while maintaining high quality.

cs.SE↗