[applfanboysbgon]

The person was specifically suggesting hiring extra developers for maintenance. While I'm familiar with the concept that "nine women can't birth a baby in a month", I don't think that applies so much to maintenance of old code paths. Apple makes over $100b in net profit per year, a truly unfathomable amount of money, they can afford it, and I think not only can they afford it but that it would benefit them. Even if only 1% of your users use X, for Apple that might translate to perhaps 10 million people using X, or at 0.1% 1 million. Hiring a dev to improve the experience for that many people just makes sense at scale, software is write-once reproduce-a-million-times-for-free.

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.

[dwaite]

My estimate is that your lower count of people who could still be using Time Capsule is off by a factor of 20, but we'll continue with the idea that Apple could justify hiring a single engineer to be assigned full-time on the TimeCapsule, starting today.

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.

[alwillis]

> Even if only 1% of your users use X, for Apple that might translate to perhaps 10 million people using X, or at 0.1% 1 million. Hiring a dev to improve the experience for that many people just makes sense at scale; software is write-once, reproduce-a-million-times-for-free.

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...