4 ms·

Remember to consider all aspects related to liability, terms of service, and so on, as it relates to security. Does your app connect to the Internet, network, o

Remember to consider all aspects related to liability, terms of service, and so on, as it relates to security. Does your app connect to the Internet, network, or make use of user logins or similar information? If it does, you cannot just let customers keep using an old version forever and not get security updates. Keeping old versions secure will be costly for you, so you always want people on the current version. "Standalone" in 2020s is not the same as the 90s. Subscriptions, while people may not like them, are a good solution for a host of less obvious problems. How do you make a decision now so that you're not stuck in 5 years' time? Go with subscriptions and continuous updates and monitor whether customers really care. If your target market is business users then don't take the HN view on whether subscriptions are bad.

huhtenberg 4y ago
Any concrete examples of liability being brought up against a developer? The theory is one thing, the reality is another. Continuous updates are universally treated by developers as a carte blanche for any changes, including drastic reworking of the UI, refactoring established features and generally messing up user experience. So the resistance to this model is very real and well justified for that reason alone, without considering the subscription aspect of it. * Besides, if a developer screwed up so badly that a patch is required, it's only fair and reasonable for that patch to be provided pro bono.
- warrenm 4y ago
  >if a developer screwed up so badly that a patch is required Required patching isn't necessarily due to a "developer screw[ed] up" - it's as likely to be that an upstream package has a discovered vulnerability, or something like the Intel fiasco from a few years ago, etc Don't assign to illwill or incompetence what's more likely to be accidental, or ignorance
  - huhtenberg 4y ago
    Intel case was an extreme exception. Irrespective of the root cause, all critical issues are still ultimately on the developer and it's the developer who should absorb the costs. If they can't afford that or can't do it in a way that's not disruptive to the normal use of the software, then it's still their problem, not users.
    - warrenm 4y ago
      you're not a dev, I see
      - huhtenberg 4y ago
        ... and you must be from sales.
        deleted 4y ago
        [deleted]
        warrenm 4y ago
        lol nope but nice try (and thanks for admitting you don't understand the problem, and instead want to unilaterally blame someone else for something which likely wasn't their problem)

huhtenberg 4y ago

Any concrete examples of liability being brought up against a developer? The theory is one thing, the reality is another. Continuous updates are universally treated by developers as a carte blanche for any changes, including drastic reworking of the UI, refactoring established features and generally messing up user experience. So the resistance to this model is very real and well justified for that reason alone, without considering the subscription aspect of it. * Besides, if a developer screwed up so badly that a patch is required, it's only fair and reasonable for that patch to be provided pro bono.

warrenm 4y ago
>if a developer screwed up so badly that a patch is required Required patching isn't necessarily due to a "developer screw[ed] up" - it's as likely to be that an upstream package has a discovered vulnerability, or something like the Intel fiasco from a few years ago, etc Don't assign to illwill or incompetence what's more likely to be accidental, or ignorance
- huhtenberg 4y ago
  Intel case was an extreme exception. Irrespective of the root cause, all critical issues are still ultimately on the developer and it's the developer who should absorb the costs. If they can't afford that or can't do it in a way that's not disruptive to the normal use of the software, then it's still their problem, not users.
  - warrenm 4y ago
    you're not a dev, I see
    - huhtenberg 4y ago
      ... and you must be from sales.
      - deleted 4y ago
        [deleted]
      - warrenm 4y ago
        lol nope but nice try (and thanks for admitting you don't understand the problem, and instead want to unilaterally blame someone else for something which likely wasn't their problem)