I'm trying to figure out a way to analyze code longevity in open source projects: that is, how long a specific line of code is active and in use.

My current thinking is that a line of code's lifespan begins when it is first committed, and ends when one of the following occurs:

  • It's edited or deleted,
  • Excluded from builds,
  • No code within its build is maintained for some period of time (say, a year).

NOTE: As clarification on why an "edit" is being counted as "death", edited lines would be counted as a "new" generation, or line of code. Also, unless there's an easy way to do this, there would be no accounting for the longevity of a lineage, or descent from an ancestor.

What else would determine a line of code's lifespan?

  • 2
    "how long a specific line of code is active and in use" why do you think this is a good metric?
    – Pieter B
    Nov 27, 2015 at 8:32

3 Answers 3


Andy Ozment looked at OpenBSD in 2006 with the same sort of question: Milk or Wine: Does Software Security Improve with Age?

You may be able to learn from his definition. It's also a very interesting paper, with an interesting conclusion as well, one that hasn't been incorporated into software management lore:

Over a period of 7.5 years and fifteen releases, 62% of the 140 vulnerabilities reported in OpenBSD were foundational: present in the code at the beginning of the study.

It took more than two and a half years for the first half of these foundational vulnerabilities to be reported. We found that 61% of the source code in the final version studied is foundational: it remains unaltered from the initial version released 7.5 years earlier. The rate of reporting of foundational vulnerabilities in OpenBSD is thus likely to continue to greatly influence the overall rate of vulnerability reporting.

We also found statistically significant evidence that the rate of foundational vulnerability reports decreased during the study period. We utilized a reliability growth model to estimate that 67.6% of the vulnerabilities in the foundation version had been found. The model’s estimate of the expected number of foundational vulnerabilities reported per day decreased from 0.051 at the start of the study to 0.024.

  • 1
    +1 @Bruce Ediger: Awesome, thanks -- looking at it right now!
    – blunders
    Jun 8, 2011 at 17:13
  • Again, thanks, so the only information I'm able to find of use is "We learn that 61% of the lines of code in today’s OpenBSD are foundational: they were introduced prior to the release of the initial version we studied and have not been altered since." - which while interesting, not really related. Everything else appears to focus on how long it takes vulnerabilities to be fixed, which again, interesting, but says nothing about factors to account for in code lifespan. Is there something I'm missing?
    – blunders
    Jun 8, 2011 at 21:55

I don't think there is an answer for that. It's highly project dependant. Some are more stable over the years, others are more volatile/refactored/evolving over the years.

Moreover, it's difficult to measure. Is an editted line really the end of it's lifespan? What about only a cosmetic change like reformatting the codebase with tabs or spaces? IMHO that doesn't count as renewed codebase, but it would according to your criteria.

That said, I think a good chunk of the LOCs live forever.

The reason is simple: it's way easier to add new code rather than to remove some. Especially when the system is complex and grown over the years. It then quickly comes to a point where it's "risky" to remove or change non-trivial code. It could introduce bugs, break compatibility, introduce a butterfly effect of changes... So I think, the bigger the codebase becomes, the older it is, the more the LOCs are going to stay.

Moreover, only good programmers tend to cleanup codebases and reduce the lines. All others tend to pile up the LOCs. And so far, the latter are winning by far. ;)


Deleting or excluding a line of code definitely is an indication of the end of its lifespan.

Regrading editing, I would ask this question: Does this statement produces a different outcome after the edit?

If the answer is yes, then I'd say the previous statement is no longer available, otherwise I'd still consider it as the continuation of the previous statement.

Example of changing the outcome:

if ( a && b )


if ( a || b )

Example of continuing the lifespan:

foo.bar( baz );


foo.prototype.bar.call( this, baz );

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.