Hacker News Reader

Comment by brushfoot | Hacker News Reader

Strongly suggest perpetual licensing unless this is truly a service, i.e., you're offloading processing to the cloud (which frankly would be a deal-breaker for me if I were evaluating this for a client).

If this is a standalone binary, what I'd want to see as a user would be a one-time purchase and an optional annual support plan.

View on HN

My other two products are perpetual licences with optional paid major upgrades and include support. But the world is changing and a yearly sub is attractive for vendors. Simple and with a more predictable cash flow. It also incentivizes the vendor to keep existing customers happy, rather than always chasing new customers.

"Everything-as-a-service" is definitely attractive to us the vendors, but I'm talking about the user experience.

With a recurring license, I'd expect:

  - Cloud computing
  - Cloud storage
  - Real-time collaboration
  - Hosting

Vendors rarely deliver on the promise of continuous improvement quickly enough that I could justify the recurring cost from that standpoint alone. Or I'm already happy with the features, so I'm just paying for feature bloat at that point. (That's definitely been the case for most of the consumer cloud apps I pay for ... which is why I'm slowly migrating back to the desktop in many areas.)

If there are no service features like real-time collaboration, then a recurring revenue model makes even less sense.

I mean, I get it—I've written software that I sell with annual licenses myself. But it depends on cloud services to work, so there are costs to me too. That's I think where it's maybe the place to step back and look at the architecture and whether it's better suited to a web app if recurring revenue is important. Just my two cents....

I agree. I'm developing something, and while a subscription is attractive to me, I feel it's not correctly aligned to what users deserve.

I'm burned out by all of these subscriptions and trying to go back to my "roots".

I pay a sub for some desktop software I use. I don't have a problem with it.

If you estimate that the average user will use the product for N years, you can charge a one-time fee of X or a yearly sub of X/N and make the same amount either way (assuming you got N right and forgetting inflation). A yearly sub is very simple to explain. And people who use the product for longer pay more, which seems fair. The sub also helps to finance the ongoing costs of development and support.

I disagree - as a vendor I think you should charge based on the value you provide to users, not the costs to run your service. That is to say I don’t think desktop software needs to have a “cloud” piece to it to make it valuable enough to users to justify an annual charge. Users don’t usually care where your app or service runs, just that it solves their pain points quickly and easily.

The question then becomes how you justify that charge, but I think you can legitimately say support and/or new feature development (especially if you allow customers to have some kind of input into that). Having guaranteed support from a company with the technical chops that Andy has would be worth it alone for me in this instance.

Jetbrains have an interesting model with their IDE’s whereby you can fallback to a perpetual desktop license for their products if you don’t want support or updates. Perhaps that’s a nice compromise option.

> you should charge based on the value you provide to users

Yes, but not infinitely, not for a static product. Otherwise I should also be willing to accept infinite punishment for whatever harm my product does as long as it exists.

If I create a hammer, it could still be generating value in a hundred years, but it could also be used to break windows and kill people. So if I deserve continuous payment, shouldn't I also be liable for the damages? Why should I be infinitely rewarded just because my tool had the potential to add value when it also had the potential to do harm?

> Having guaranteed support [...] would be worth it

I agree with you there. But I think it should be optional. It sounds like that's what JetBrains is doing, albeit in a roundabout way.

Reply on news.ycombinator.com