I also don't quite get people's attachment to FTP. FTP has always been a horrible protocol and only relatively tolerable back before the Internet got so widespread. The moment one went from a modem to say, DSL, one would quickly bump into the horrors of FTP under NAT. And even before then, FTP sometimes screw up hours of downloading with ASCII mode.
FTP is clearly a protocol made for command-line comfort, and was never a good fit for something like a web browser anyway. The directory listing is an atrocity because it's made for human eyes and requires a dozen different parsers for automation depending on variety. The mess with the passive/ASCII stuff requires the user to understand those are things that exist and what they may want. And the hacky anonymous download access was achieved by giving the user instructions in the login banner.
All those things are really not suitable for anything that aims to make it simple to download on click.
GUIs did not exist when FTP was made. Frankly, the concept of user accounts didn't either, so the anonymous access hack was a product of its time and not an intentional design decision.
I am confused though, because FTP being a protocol means it is fairly standardized in terms of commands and expected output right? Are there FTP servers that spat out wildly different responses to typical commands? Because if so, SMTP/POP3 should suffer from the same thing, but I don't recall many email client developers complaining about it.
You appear to have a choice between a browsers with feature parity, except one of them supports your privacy more.
Like "this type of reasoning" is what happens whenever you reach a point where you get resource constrained (even Chrome/Chromium has to pick how to allocate their resources). Eventually you need to pick what to work on, and what to keep maintaining.
To be honest the main reason I have to keep Firefox as my default browser is that I'm used to the developer tools and I like them better than Chrome's. But it's gotten to the point where I have to tell myself that it wouldn't make any sense to drop those, but I thought the same when they dropped all the other features, so I find it harder and harder to stay optimistic.
Same thing with premature, or otherwise unnecessary, optimization. Sometimes it's just fun!
In OP's situation, it sounds like their counterpart is trying to argue that this project is a "good thing to do" for the user/system. In reality, it's a bit of code hygiene that makes it more fun to do work (still important [1]).
That dissonance hides the true value of the work and makes it difficult to reason about.
a bad manager would.
But also, an engineer capable of this is basically CxO material - which threatens said manager's career progress!
This is a really good (initial) framework for thinking about what new features should or should not be built.
But I would advise against using it (alone) as a tool for deciding which existing features should be removed (as other readers suggest may be happening).
With new features, it's a binary choice - build or not.
With existing features, there is a third choice - continue development, stop development (but maintain), or remove feature. Removing features has costs that might not be worth the savings.
Google lost a lot of goodwill over the last few years by unceremoniously dropping products. Mozilla, over the last year or so, seems to be making some of the same mistakes.
Chromium is terrible enough that users don't really have an alternative - at the moment. But goodwill is really hard to get back after it's been squandered.
