3 ms·

> I think I might be the only one on the planet that tries to avoid tooling like this that's tied to a subscription I think it depends on the app. If it's some

> I think I might be the only one on the planet that tries to avoid tooling like this that's tied to a subscription I think it depends on the app. If it's something that I use frequently I want a subscription. Otherwise, not. The reason for that, is that I look at subscriptions as something I have to be convinced to continuously pay every month. That gives me a lot of power to just disconnect at a later time, and this means that those apps tend to listen to user feedback more often than other apps.

donmcronald 3y ago
> If it's something that I use frequently I want a subscription. Otherwise, not. The reason for that, is that I look at subscriptions as something I have to be convinced to continuously pay every month. I don't agree. I'm fine with the economic idea of a subscription in terms of creating recurring revenue for developers and think a loyalty discount is a good way to convince people to keep paying, especially for tools that are used moderately to frequently. I want the latest and greatest version of the software I depend on and I don't mind paying for it, but I want to be able to stop paying at any moment and have the only downside be a loss of loyalty discount. On the workflow / risk side, cancelling a subscription is, by design, intended to be punitive. As soon as you stop paying, the vendor revokes access to your tooling and you're workflow is disrupted. The intent is for it to damage your businesses and processes enough that cancelling becomes extremely painful. Even the Jetbrains model that everyone seems to love is a total sham because cancelling is designed to damage your development process by forcing you to roll back to a year old version of the software.