3 ms·
>~2% of users 2% seems pretty high! If you make 50-70 kinds of these project management feature-drop decisions, then if the groups are mostly distinct, you'll
by logicallee 12y ago
>~2% of users
2% seems pretty high! If you make 50-70 kinds of these project management feature-drop decisions, then if the groups are mostly distinct, you'll have dropped 100% of your users (2% * 50 or 1.42% * 70 = 100%.)
Think of it this way. If only two percent of your users have a first name that isn't in the top hundred first names in America, would you drop support for first names that aren't on your whitelist, in some form field? (because you want it to contain real data.)
I think it's better to think through the rationale for dropping support (for example: If the people using this feature have a clear alternative, that is also better, and that they know about and will try and like. Then it might be acceptable In the first name example, the only rationale would be if this were some kind of game or something and people weren't expected to use their actual first name, and you also present them the list. Then it might work.)
The rationale presented here is very weak. "Only highly-paid people (developers) trying to get work done use this, about 2% of our sales." Marketing win?
- cnvogel 12y agoIt's not that bad in practice ;-)... Let's assume random distribution of used features among your customers. If you shoot randomly at your users with a 2% hit rate [alienate them by dropping a feature], your user will stay with your product with 98% probability. Do it 50 times, any user will have a 0.98^50 = 36% chance of not having been hit [having at least one important feature taken away from him that makes him stop using your product...], so only (100%-36%) 64% of users will drop your product and go elsewhere.
- nitrogen 12y agoSomeone should have explained this to the GNOME team.
- Intermernet 12y agoIt's putting a positive spin on Xeno's Paradox. 100% minus 2% leaves 100% of the remainder! Until you remember that the quantum of a user-base is a user. I really don't know why they haven't adopted the (already existing) code from Android, or maybe even Gnome, KDE etc. that seems to solve the problem they purportedly face. If other projects (one of which is also a Google product) have solved this, why can't the ChromeOS team? I may be being naive, but why hasn't this issue arisen in other, similar projects? I understand that they want to keep the codebase simple, but keeping HFS+ and VFAT while ditching ext* due to possible future security issues seems like a cop-out.