AFP and Time Capsules add attack vectors to the OS, which can be targeted even when few users actively using them. One dev could keep both basically functional, but to what end? User counts are already small, and people that aren't using them are still exposed by their mere existence.
Shrinking or removing code, in my experience, is one of the biggest single wins you can have in software development. Less to test, less to update, less to secure.
Development is a finite resource, the argument here is to allocate them to hard-to-secure, outmoded, replaced, technology instead of anything future relevant. It doesn't make sense.
I have no doubt the bean counters have drawn up every kind of spreadsheet they can imagine trying to quantify it as being not worth it, but I don't think these kinds of quality of life things can be easily quantified, because each small thing maintained might only impact a small number of users but collectively, all of these kinds of small things add up to either a system with sharp corners that constantly papercuts the user (current Apple software), or one that is so seamless that it engenders customer loyalty for decades (old Apple software). This kind of shortsighted penny-pinching is how companies become a shell of their former selves, suffering a slow death-by-MBA.
This hypothetical employee would:
- update the TimeCapsule firmware from using AFP to using a brand new SMBv3 implementation, including both porting and making it "fit" within the constraints of 2013 hardware.
- be designing and implementing a migration system for both the TimeCapsule and the Mac to move to using the new implementation
- be responsible for all security analysis, QA, and documentation for the firmware and migration system
They also need to get it done by the first macOS version that has AFP removed, which will land in developer preview in six weeks and need to be feature complete in about 17 weeks.
If Apple hires a new developer capable of doing that, I don't want them to relegate them to supporting 13 year old hardware. I want them improving things that the majority of users actually need.
And that is the core problem with this sort of argument. Even with infinite money or the infinite possibilities of open source contributions, the availability of talent is still _always_ finite.
If Apple is known for anything, it's that they keep moving ahead with the operating system, even if it means leaving some users behind… and that goes back to the late 80's/early 90s when apps had to be "32-bit clean" [1] to run on System 7 and newer Motorola 68000 processors like the 68020, 68030, etc.
Some beloved apps don't make the transition, and that happens with every technology transition like 68000 to PowerPC, then to Intel, and then to ARM. And of course, from Classic Mac OS to OS X, Mac OS X then macOS.
I've been active in user groups since the Apple II days; there's a cohort who mostly won't upgrade their hardware but complain bitterly that they lack certain features. Or they attempt these fragile and unreliable hacks to keep their old hardware and software running.
Usually, they're doing themselves more harm than good, especially if they're not technical.
Also, it's pretty unlikely recent college graduates would be able to tackle old C++ or Objective-C code written before they were born, in some cases, to keep something like AFP alive. Regardless of Apple’s financial success, it's not a good use of resources to keep a bespoke network protocol going that originated in 1985 that less than 1% of the installed base is actively using.
[1]: https://en.wikipedia.org/wiki/Classic_Mac_OS_memory_manageme...
cf Linux removing old network drivers this week for the same reason (without the hand-wringing that this Apple announcement is getting!)
Apple's source is not public, but the protocol is still fully documented if someone wanted to create a new client and server. https://developer.apple.com/library/archive/documentation/Ne...
However, they'd be better off just creating a driver and server around the open source Netatalk implementation.