25
Subscription models for an app that’s not hosting anything is just the dev wanting a constant revenue stream, no matter how they try to word it. (sh.itjust.works)
submitted 3 years ago by to c/lemmy@lemmy.ml
81 comments fedilink hide all child comments
 

Subscription models only make sense for an app/service that have recurring costs. In the case of Lemmy apps, the instances are the ones with recurring hosting costs, not the apps.

If an app doesn’t have recurring hosting costs, it only makes sense to have one up front payment and then maybe in app purchases to pay for new features going forward

you are viewing a single comment's thread
view the rest of the comments
[–] 1 point 3 years ago (1 child)

Games are a good example. One might want to publish a game and then work on the next game, not go back to the first game again and add dynamic permission prompts for the accelerometer or recompile with the new SDK or whatever. But someone also might want to play Space Grocer I before Space Grocer II-X to get the whole story.

The fewer breaking changes there are, the lower the burden of an app being "supported" is. Someone might be willing to recompile the app every couple years, or add a new required argument to a function call, but not really able to commit to re-architecting the program to deal with completely new and now-mandatory concepts.

Even on software I actively work on that is "supported" by me, I struggle with the frequency of e.g. angry messages demanding I upgrade to new and incompatible versions of Node modules. Time spent porting to new and incompatible versions of a framework is time not spent keeping the app worth using.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 3 years ago

    Games are actually a really bad example. They're generally not written from scratch and use an engine. So there's usually not a lot of work to keep it up to date. When they don't make enough money from it though, they will retire it. It happens.

    And Node modules? Are you kidding. The constant updates are usually security patches. If you're properly using semver then it shouldn't be an issue. You can either stick with the major or minor release depending on your needs. But those packages are also in your boat. Someone is developing them and patching them. They may drop old minor versions because they can't support that many different releases. Because backwards compatibility is expensive.

    Seriously, please tell me you're at least securing whatever application you're writing. Do you even do an npm audit (or yarn, whatever you use) and patch the findings?

    Especially in web development, security is absolutely important. Sometimes yeah, you may not implement a feature. But that's because your app lacks development resources like another developer. I'm sure it's great to keep working on the exciting stuff like new features. But the "boring" stuff is still damn important.

  • permalink
  • fedilink
  • source
  • parent