Six years after the Linux Foundation and the Inclusive Naming Initiative began pushing projects to retire terms like master/slave and whitelist/blacklist, a new audit of 461 LF repositories1 finds the job a little more than half done: non-inclusive terminology is down roughly 47% since 2020, but 62.7% of those repositories still contain at least one Tier-1 term1, and large language models can reconstruct renamed identifiers from surrounding context. The renaming backlog now doubles as training data.
What did the NISCAN audit actually measure?
NISCAN, the tool behind the study, is a multilingual static-analysis framework that detects non-inclusive terminology across source code and related software artifacts using the Inclusive Naming Initiative’s vocabulary, and its authors ran it against 461 Linux Foundation repositories1 with history reaching back to a 2020 baseline. The paper, “From Codebases to LLMs: Non-Inclusive Naming in Linux Foundation Repositories” (arXiv:2607.02772, cs.SE), was submitted on 2 July 2026 and revised ten days later, so everything public about it so far rests on a preprint less than three weeks old.
The vocabulary being counted is deliberately plain. The INI operationalizes the ordinary dictionary sense of “inclusive,” which Dictionary.com gives as “language or terminology that does not exclude a particular group of people and that avoids bias, stereotypes”; Merriam-Webster’s definition reads similarly. On top of that vocabulary the study applies severity tiers and reports the headline prevalence figure against Tier-1; master/slave and whitelist/blacklist are the pairings the LF and INI have urged projects to replace since 2020. The abstract does not publish the exact tier definitions, so the tier roster and any finer-grained classifications will have to wait for the full text.
What makes the study new is coverage rather than sentiment. Since 2020 the Linux Foundation and the multi-organization INI have encouraged exactly these replacements, and by the authors’ account the recommendations were widely adopted. What has been missing is a long-term empirical measurement of adoption across the whole LF estate. Prior coverage was announcement-driven: a high-profile default-branch flip makes the news, a stale configuration key does not.
How much naming debt is left after six years?
Two numbers have to be read together: terminology volume fell by approximately 47% against the study’s 2020 baseline1, while 62.7% of repositories, roughly 289 of the 461 audited, still contain at least one Tier-1 identifier.1
The pair is consistent once you notice what each measures. The decline is a volume measure: across the LF estate, occurrences of the tracked terms dropped by nearly half, which matches the picture of broadly successful adoption. The big, visible renames happened. The prevalence figure counts any repository with a single leftover occurrence, so it measures unfinished migrations rather than untouched ones. The likely shape of the data is a long tail: most projects renamed the prominent identifiers, fewer swept the prose, and one forgotten master in a deployment manifest keeps the repo in the residual set.
Two caveats apply. First, the 2020 baseline’s construction is not visible in the abstract, so the 47% should be treated as the authors’ measurement against their own reconstruction of repository history, not an independently reproduced figure. Second, six years is long enough that “we’ll get to it” stopped being a plan. Whatever remains at this point is not backlog in the agile sense; it is debt that projects have, in effect, decided to carry.
Where does the leftover terminology live?
Mostly outside the code: the study finds the bulk of the remaining non-inclusive terminology sits in documentation, comments, configuration files, and other software artifacts, which means a code-only sweep misses most of the residue.
There is a mechanical reason the residue concentrates there. Renaming identifiers in source has forcing functions: builds break, tests fail, downstream consumers file issues, and the tooling (codemods, linters, plain grep) was built for exactly that job. Prose has no compiler. Comments are written once and read by almost no one. Documentation drifts from the code it describes. Configuration keys have the worst half-life of all, because they get copied into packaging scripts, container images, and deployment manifests that nobody revisits until something breaks. The README outlives the refactor.
The practical consequence is that the standard rename playbook, find-and-replace over identifiers plus a linter rule, declares victory early. An artifact-wide sweep is a different kind of work: prose occurrences need judgment rather than blind replacement, because some are legitimate historical references (a changelog entry describing the rename, a migration guide that has to name the old key) and some are not. NISCAN’s design is the paper’s implicit answer to this: multilingual, artifact-aware static analysis rather than an identifier linter. But the location finding stands on its own, and it is the part maintainers can act on without touching the authors’ tooling at all.
Why doesn’t foundation policy predict which projects renamed?
Because the variables that matter are local: the study finds repository size, programming language, project functionality, and ecosystem predict term inclusiveness in LF repositories more strongly than foundation governance, so top-down LF policy is not what moves individual projects.
That is an uncomfortable result for a governance-first strategy, and it is worth reading precisely. It does not say governance is irrelevant; it says governance is out-predicted. A foundation can publish vocabulary guidance, and the INI tier lists exist for exactly that purpose, but execution is per-repository labor funded by maintainers with other priorities. Policy statements are the cheapest artifact a foundation produces. The properties that actually sort migrated projects from unmigrated ones belong to the projects themselves: how much text they carry, what language and tooling surround them, what they do, and which community’s norms they inherit.
The second-order consequence is a budget question. If governance is not the lever, then a foundation that wants movement should fund the work directly: artifact-wide scanning across its hosted projects, migration tooling, engineering time for sweeps. Another revision of the language policy changes the foundation’s own document repository. It does not change anyone else’s.
This is a correlation finding reported at abstract level, without published effect sizes. “Stronger predictor” is doing real work in that sentence, and the full paper will determine how much.
How do renamed identifiers survive inside LLMs?
Through context: in the paper’s case study, large language models reconstructed legacy non-inclusive identifiers from surrounding program text, showing that historical naming decisions remain embedded in model predictions even after the identifiers themselves have been renamed.
The mechanism is not mysterious once you remember what code models train on. Crawled source contains the past: pre-rename snapshots, long-lived forks, mirrors, vendored copies, and years of secondary material quoting old names. Given function bodies, comments, and call sites that co-occurred with the old term across a large number of examples, the model’s probable completion is the name it saw most often, and for any project that spent years under the old vocabulary, that is the old name. A maintainer can land a perfect migration and still watch an editor suggest the pre-rename identifier, because the model’s picture of the project predates the migration. State on the default branch and state inside the model diverge, and the model catches up only as crawls refresh and stale copies age out of training corpora.
Even with the magnitude unknown, the authors’ framing shifts the cost accounting. They describe the residue problem as one of “responsible naming and ethically sourced code generation”: terminology left in repositories is a training-data quality issue, not only a community-standards one. Under that framing, every un-renamed occurrence in a crawlable repository is a small training signal republished on every crawl, and the 62.7% prevalence figure doubles as a rough measure of how much LF-hosted vocabulary is still teaching models the old terms. Slow migrations do not only leave debt in the repo. They feed it forward into the next model’s suggestions, which then get written back into new code by contributors who never saw the original debate.
What should a maintainer do about the backlog?
Fund an artifact-wide sweep instead of an identifier rename, sequence code-facing names separately from prose, and verify with a rescan, because a single leftover occurrence keeps a repository in the 62.7%.
Scope. Audit source, documentation, comments, and configuration together. The location finding says the residue is mostly outside the code, so the identifier linter is the beginning of the job, not the end of it.
Tooling. The study is an existence proof that artifact-wide static analysis over the INI vocabulary is buildable, multilingual detection included, which matters because residue in non-English documentation counts too. Whether NISCAN itself is released is not stated in the abstract, so plan around tooling you can actually obtain: a maintained linter for code, a vocabulary scan over prose and configs, and human review for the occurrences that need judgment. Manual review alone does not hold up past a handful of repositories.
Sequencing. Code-facing names (default branches, configuration keys, CLI flags, API fields) carry compatibility cost and deserve deprecation windows. Docs and comments carry none and can be swept immediately. Which half to fund first is a judgment call, but the paper’s feedback-loop argument favors clearing the highest-visibility files early: the README, the docs landing page, the sample configurations that get copied into the wild. Those are the occurrences most likely to be read, quoted, and crawled.
Verification. Rescan after the migration lands. Expect stragglers in generated files, changelogs, and translated documentation, and expect model-based tooling to keep suggesting the old terms for a while after you finish. Your migration being done and your editor agreeing with you are now two separate events.
The practical verdict: this study converts a values argument into an operational one, and that is what makes it useful for prioritization. If you maintain an LF-hosted or LF-adjacent project, the prevalence figure is your prior: better-than-even odds that your repository carries at least one Tier-1 term somewhere outside the code. The location finding tells you where to look. The reconstruction case study tells you why deferral costs more than it used to, because the terms you leave are the terms the next code model suggests back to your own contributors.
What can’t this study tell us yet?
The durable findings are the prevalence and location numbers; nearly everything about mechanism strength is still unreported, because the public record is an abstract and a preprint that was revised on 12 July 2026.
| What maintainers want to know | Reported | Not yet reported |
|---|---|---|
| Overall progress | ~47% decline since 2020 | How the 2020 baseline was constructed |
| Prevalence | 62.7% of 461 LF repos carry at least one Tier-1 term | Per-project, per-language, and per-ecosystem breakdowns |
| Location of residue | Mostly docs, comments, configs, other artifacts | Per-artifact occurrence counts |
| What drives renames | Size, language, functionality, ecosystem out-predict governance | Effect sizes for any predictor |
| LLM impact | Models reconstruct renamed identifiers from context | Which models, how often, with what confidence |
The right response is asymmetric. Acting on the artifact-wide finding is low-regret regardless of how the LLM numbers eventually shake out: sweeping docs and configs is cheap, reversible, and justified by the location data alone. Citing the reconstruction result quantitatively is not yet justified, because there are no published quantities to cite. Expect the 47% and 62.7% figures1 to be the numbers this paper is remembered by, and expect the full text to be stress-tested on exactly the rows in the right-hand column.
Six years in, the finding is not that open source failed to rename things. It is that renaming the code was the visible half of the job, and the invisible half is already sitting in model weights.
Frequently Asked Questions
How long will LLMs keep suggesting renamed identifiers after we migrate?
At least two years, probably longer. Code crawled before your migration enters training pipelines with a substantial lag, and models train on historical corpora that include pre-rename snapshots, forks, and vendored copies. The editor that knows your new terminology may not exist yet.
Why do code-only linters miss most of the terminology debt?
Because most non-inclusive terms live in artifacts without mechanical forcing functions. A broken build forces an identifier rename, but nobody compiles a README. Documentation drifts from the code it describes, configuration keys get copied into deployment manifests that no one revisits, and comments persist long after the identifiers they reference change.
Does foundation governance drive inclusive naming adoption?
Less effectively than you would expect. Repository size, programming language, project functionality, and ecosystem are stronger predictors of term inclusiveness than foundation policy. Policy statements are cheap, while execution is per-repository labor funded by maintainers with competing priorities.
Which high-visibility files should a resource-constrained team prioritize?
Start with the README, main documentation landing page, and sample configuration files. These are the artifacts most likely to be read, quoted, and crawled, so clearing them early reduces the training signal even if you cannot fund a full artifact sweep immediately.
What makes the Linux Foundation terminology uniquely consequential?
The kernel sits at the center of the ecosystem and is widely considered the largest open-source project, so terminology in LF-hosted code propagates with unusual reach into crawled code corpora. A single project’s vocabulary choices, when copied at that scale, teach models the terms they will later suggest back to contributors.
