Lee DSilver badge
Reply Icon
The primary reason to remove code is maintenance burden.
Every time you want to change some underlying API, or migrate to a new primitive, or introduce new locking, you have a bunch of old code that receives really quite devasting changes that can't be automated... and there's nobody using or maintaining that code to check it still works properly in all possible instances. Then some pillock boots it up on their NAS products as part of their natural firmware upgrades, and it starts trashing customer's NAS data because of some niche side-effect, and now you have a major NAS vendor telling its customers that Linux isn't reliable and just trashed all their customer's filesystems.
As soon as something falls out of active maintenance, it has to be marked for deprecation to let people know not to use it, and if nobody steps up to maintain it, it gets removed.
Lack of maintenance is literally the primary reason for code removal in the Linux kernel. Things that should have been removed decades ago were still actively maintained, so they were allowed to stick around until the last maintainers left (not the last users!). Similarly, things that were brand-new but didn't have adequate maintenance were removed and pushed back out of tree. In fact, one of the main reasons for being refused to be pulled in-tree is that someone then has to maintain it forever. And that's a huge burden for code they may not understand, so it can take DECADES to get code into mainline simply because you have to break it down and get every piece in and slip it past all the maintainers before you ever get close to actually merging the final product, and then you have to prove that enough people will use it so that enough people will be around to maintain it so that kernel maintainers aren't spending half their life trying to fix issues in other people's code that they don't understand.
And this severely affects security. One locking or permission change, and if you don't go updating all your code you are leaving security holes in the kernel. That can't be allowed. And if there's nobody around to say "Yeah, I've fixed bcachefs against this new novel attack that we're seeing throughout the kernel code" then it gets removed. Quite rightly.
People think it's personalities, or technicalities, or some desire to just move into every new thing and throw away every old thing (which is utter nonsense, Linux supports some ridiculously antique stuff still), it's not. It's about maintenance. The one thing Linux lacks is good maintainers with time on their hands to do that job, usually for free! Those are the most valuable and precious resources. And, as things like NTFS filesystem support cough Paragon cough, whole-kernel mass-patches that nobody is willing to break down (cough grsecurity cough) etc. have found out... it doesn't matter how great your code is, if people aren't willing to maintain it you have a decades-long uphill battle to get it into the kernel, let alone keep it there.
Nobody wants to babysit your code in perpetuity, especially if... when a new maintainer is required... not one competent, trusted person is willing to step up and say "I'll do that".
