Criteria for Obsolence
This is a set of draft criteria for determining when it's time to remove something from the project's repo, and/or move it to ports. It's not all inclusive, and every one of these things comes down to a cost-benefit analysis: do the pros this process comes up with out-weigh the cons? Are the benefits greater than the costs? etc. It likely needs refinement, but is what I've used when removing older arm and mips ports, as well as some of the old SCSI drivers. It also draws on the 10/100M ethernet pruning we just did. It outlines how to evaluate technology, but proscribes no process. That's for another document.
1. Relevance
How relevant is this code to FreeBSD. This should be rated on a scale of high (everybody uses it) to very low (nobody uses it).
For example, as of this writing, amd64 would be rated high relevance. chaosnet would have a very low relevance (nobody uses it). armv5 would have a low relevance (there's some evidence of people using it recently). 100M ethernet apparently has medium relevance as there evidence more than a handful of people are using 100M nics.
However, be cautious here. For example, not all 100M nics are equal. Dozens of them aren't used at all, while there's 4 or 5 that are quite popular in that niche.
This should be viewed in the 'how much does this feature make/enable people using FreeBSD' sense of benefit. Current popularity is elsewhere.
2. Functionality
Does the technology even work? Does it compile? Does it run? Has it been verified to work on a reasonable load?
While people's notions of 'reasonable' may very, one should try to assess what the 'median' or 'average' of people's views are on the topic. While there will be some outliers that insist a 100MHz 16MB machine can handle a reasonable load, most will agree it cannot due to memory limitations.
3. Benefit to the project
How beneficial is this technology to the project, irrespective of how well it works, or how popular it is. In the past, for example, the project allowed Juniper to maintain the build system back several major versions because their build machines were stuck at old revisions. This had a tangible benefit to the project, as Juniper continued to ship product based on FreeBSD and was able to bring changes from their product into current easily.
On the other hand, even though the Atmel arm port brought a lot of benefit to FreeBSD/arm in general, and allowed FreeBSD to run on a wide range or products from a company that contributed much to the project. By the time it was removed, however, it was providing no benefit to the project because FreeBSD had grown too large for the chips it supported, and successor chips were not supported by the port (with no prospect for a port on the horizon).
4. Cost to the project
How much extra 'tax' does having the code in the tree cost? Every driver that's in the tree costs us an hour or two a year when developers make sweeps through the tree. Sometimes this cost is looking at false positives from a grep, sometimes it's extra code changes, sometimes it's just kernel bloat.
Each architecture we support acts as a drag on supporting new features. For example, NUMA required changes to a number of low-level kernel interfaces. So even though it was primarily for amd64 (and to a lessor extent powerpc64), changes had to be made to arm, mips and sparc64 which had no real numa to speak of.
5. Popularity
How popular is a feature? How many people are using it? This is related to benefit and relevance, but it's the demand for a feature.
We support amd64 because hundreds of thousands (millions?) of machines worldwide run it.
Another example, one reason we still support the otherwise obsolete armv6 because the Raspberry Pi folks keep releasing new boards that have this chip on it, and there's a fair number of people using these low-end boards because they are cheap.
6. Risk to the project
Does the technology represent a risk to the project. For example, having network daemons in the tree is a risk. If it is enabled by default or mistake, it could create an attack vector should a bug be discovered bug in them. The risk varies by daemon. Some were written in the BSD4 era when all the considerations for defensive programming for security weren't well known and/or practiced. Some were written recently and incorporate many layers of protection. The risk between these two types of daemons quite different.
In addition to security risks, there may be other risks in the areas of performance, stability, IP, usability, etc.
7. Modernity
What is the age of the technology supported? Is is still produced? How long ago did it go out of production?
This factor goes hand-in-hand with popularity and relevance. Technology that's older has a higher burden of proof for relevance than technology that's younger. We won't remove something just because it is old. However,
8. Maintenance
Does the technology have an active maintainer? While some technology needs little to no care and feeding, API changes to it sometimes accidentally break it (even low risk ones have). Without an active maintainer that at least tests changes as they come in, the risk increases with each passing year that the driver no longer works at all, or has weird edge cases in newer versions that it didn't have in older ones.
9. Compliance with MD requirements
Many kernel APIs are implemented as a MI part and a MD part. Ports must comply with the requirements of the API. If there's too much non-compliance, or weak compliance, the port becomes a burden as it won't function well and/or require developer time to fix these things when the maintainers lack either the time or skill to do so.
10. Compliance with Project Policy
The project has a number of policies that it's created over the years to help in the hard calls. For example, we have no 16 bit ports. All our ports require MMUs. etc. These policies change from time to time and new policies may be put into place that effectively obsoletes old code. If a minimum memory size were set, for example, it makes no sense to support gear that cannot have at least that minimum amount of memory.