Research on technical debt in open-source software predominantly examines accumulation (how much debt exists and how long remediation is deferred), implicitly assuming that debt is observable. We argue that observability is itself the prior variable: debt that contributors cannot detect cannot be addressed, regardless of its severity. We present a multi-case empirical study of three latent debt instances discovered and retired in Apache Fineract, a production core banking platform deployed by microfinance institutions worldwide, during a four-month period of active contribution. Each case exhibits a distinct visibility signature that determined both its persistence (four to eleven years) and its detection mechanism. The starkest instance, Case B (invisible at the execution surface), is a REST endpoint fully scaffolded with database columns, permission records, and API routing, yet silently rejecting every invocation since August 2015: invisible to static analysis, documentation generators, and security scanners alike, and discovered only when a contributor attempted to implement the missing handler after nearly eleven years. Case A (visible-but-unowned): security debt documented in public CVEs and wiki advisories for years, yet unaddressed due to the absence of a responsible steward, a condition we term the maintainer gap. Case C (economically tolerated): the same loop-invariant query amplification anti-pattern recurring independently across five organizationally distinct subsystems, producing no error signals and persisting below the economic threshold that motivates investigation despite being locally visible in code. Cross-case analysis of these three instances suggests a debt visibility taxonomy and three distinct retirement lifecycles: Warn-Disable-Delete, Discover-Delete, and Detect-Fix. Our findings suggest that no single governance or tooling mechanism is sufficient to surface all three visibility classes, and that stewardship, detection, and economic-visibility interventions are complementary rather than substitutable.
A M Khan (Wed,) studied this question.