3 ms·

This is a completely broken model. You are wrong by pushing your changes on "slow to update" customers. Customers know when to update much better than you do.

This is a completely broken model. You are wrong by pushing your changes on "slow to update" customers. Customers know when to update much better than you do. If you are trying to update before they want to, you are doing them a disservice. This attitude is inspired by the desire to sell more, and often times, it means to sell more unwanted crap, where customers are trapped by the "package deal", where they are either forced to update to gain useless features and the headache resulted from various inconsistencies and defects coming from the last update, or they are unable to get the product at all (because the provider cancels support or wouldn't sell older versions etc.) In other words, you with straight face describe some really shady practice and you don't even realize how bad it sounds.

stefan_ 3y ago
Unless they have a specific problem or missing feature, customers want to update never.
actionfromafar 3y ago
It can be that, but it doesn't have to be. It depends on the business model and it's quite orthogonal to library vs service.
mrmanner 3y ago
> This attitude is inspired by the desire to sell more, and often times, it means to sell more unwanted crap, where customers are trapped by the "package deal", where they are either forced to update to gain useless features and the headache resulted from various inconsistencies and defects coming from the last update, or they are unable to get the product at all (because the provider cancels support or wouldn't sell older versions etc.) Selling more is how service providers are able to sell their generic service at a lower price than the cost you would incur by building it in-house. In other words, being forced to upgrade to accommodate features that other users want is the price you pay for sharing the development cost with those other users. That's not shady.
NBJack 3y ago
You assume I wanted to make the update in the first place. I invite you to review roll outs of security updates. These are rarely about pushing new features, and may have nothing to do with my own code at all. It might just be a version bump to my dependencies config (if a dep manager with shared libraries is involved), or just a refresh of my flatpak equivalent. But, either way, shit breaks in weird and wonderful ways, and there is little I can do but wave my arms frantically at customers.

stefan_ 3y ago

Unless they have a specific problem or missing feature, customers want to update never.

actionfromafar 3y ago

It can be that, but it doesn't have to be. It depends on the business model and it's quite orthogonal to library vs service.

mrmanner 3y ago

> This attitude is inspired by the desire to sell more, and often times, it means to sell more unwanted crap, where customers are trapped by the "package deal", where they are either forced to update to gain useless features and the headache resulted from various inconsistencies and defects coming from the last update, or they are unable to get the product at all (because the provider cancels support or wouldn't sell older versions etc.) Selling more is how service providers are able to sell their generic service at a lower price than the cost you would incur by building it in-house. In other words, being forced to upgrade to accommodate features that other users want is the price you pay for sharing the development cost with those other users. That's not shady.

NBJack 3y ago

You assume I wanted to make the update in the first place. I invite you to review roll outs of security updates. These are rarely about pushing new features, and may have nothing to do with my own code at all. It might just be a version bump to my dependencies config (if a dep manager with shared libraries is involved), or just a refresh of my flatpak equivalent. But, either way, shit breaks in weird and wonderful ways, and there is little I can do but wave my arms frantically at customers.