When is a not updated software considered deprecated in the academic world?

Question

Currently I'm writing a thesis in Computer Science for which I need to introduce and compare several open source tools that are available for performing a certain type of testing (mutation testing) on some piece of code.

To reduce the number of tools (initially more than 25), I set two limits :

1. The tool must have been updated in the last 5 years to be present in the list, otherwise it is considered obsolete.

2. Only tools that work for one of the 3 most used languages are considered. I defined them with the TIOBE index (Java, C/C++ are equivalent for the tools and Python).

I arbitrarily set the first condition to five years, but I would not be able to justify this number if needed. I didn't find a study or article with a point of view on the subject.

So my question is: After how many years without updates would such a software (or any software) be considered deprecated?

Answer 1

I don't think there is such a standard, certainly not one applicable to all of academia. For your thesis, I would suggest that it might be more useful to talk about "recently updated" / "currently developed" software, rather than labeling the rest as obsolete.

"Deprecated" signals that the creator no longer recommends using the software. I can't think of any real examples for a full software package (i.e. going beyond deprecating part of an API), but I guess it might happen if the software is known to produce bad results.

Software might be "obsolete" if it has been de facto replaced by a better option, but certainly not just because it's old. Even then, the old option might be good enough. Visit a couple of (established) experimental labs in the sciences, and you'll likely see lots of old equipment still running old software. Changing it all out would just be needless overhead, and not be guaranteed to help. There's almost always a better place to spend the money you might have... From another angle, if you consider numerical algorithm implementations and libraries as tools, there's a number of them that have gone decades without updates, yet are still routinely imported and used in new software development.

Answer 2

The most common usage of "deprecated" is quite different and has nothing to do with the date of the last update. It means that the developer (or group) responsible for the overall system (Java libraries, say) has decided that in the future the feature may be dropped or modified so as to not be backward compatible. It is a promise about the possible future, not a statement about the past.

Somewhat related, an organization, usually a large one, can deprecate the use of a piece of software, meaning that they permit employees to continue using it for company projects, but will no longer provide IT support. But that is an individual company decision and could occur at any time.

Even your "obsolete" idea is flawed. It isn't about when it was last changed, but when it last was used for important work. Software can be regularly updated, but if no one cares, it is effectively obsolete.

Of course, you may reduce the number of tools you consider to suit yourself. But you should most likely focus on the most commonly used tools, rather than ones that haven't been updated for a while. After all, a stable release is valued if it is fit for purpose. If the problem space doesn't change, older tools may have a benefit. Likewise a tool built in a domain-specific language might be quite valuable to users, so excluding it arbitrarily might be a mistake.

Answer 3

So, just two points:

1) you "set" 5 years, that is justifiable as "what can be argued is a reasonable limit", it is as valid as any other assumption as you mention there is not other study with a comparable point of view.

2) you could make a case for only admitting software that is currently being fully supported and is being updated. While older software can still be used, you have a "limit" that the software is still capable of being developed to change as developments happen.

If, as I understand, you are just "drawing a line in the sand" then making the parameters clear should be sufficient. Many can, and possibly correctly, argue that X & Y software could or should have been included, but to keep the thesis within sensible parameters of time & length then some arbitrary decisions have to be made.

Best of luck anyway.