this post was submitted on 03 Aug 2023
60 points (84.9% liked)

Lemmy

12611 readers
56 users here now

Everything about Lemmy; bugs, gripes, praises, and advocacy.

For discussion about the lemmy.ml instance, go to !meta@lemmy.ml.

founded 4 years ago
MODERATORS
 

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
[–] planish@sh.itjust.works 9 points 1 year ago (4 children)

Something has gone wrong in software development where software can never be finished.

If you release an app on Google Play and never touch it again, eventually Google will pull it from the store and customers will complain that it no longer runs on new devices. Android 16 will require that all applications now do something, and refuse to run any that do not.

This is the real structural source of the constant subscription demands. Nobody is willing to commit to supporting a stable API for 10 or 20 years, and nobody will keep coming in to bump dependency versions and rewrite systems to Google or Apple's new whims every year unless they get paid for this apparently useless work.

[–] PupBiru@kbin.social 7 points 1 year ago (1 children)

of course nobody is going to commit to supporting a stable API for 10 to 20 years… that’s expensive as heck and not even remotely worth it!

there’s nothing “wrong” with software development, it’s just that consumers demand new features rather than stagnation… i sure don’t want to be using a 20 year old app because we’ve come a long way in 20 years in so many regards

in 2003, windows xp was still microsoft’s dominant OS with vista still being several years off, half life 2 was about to be released, gmail was allllmost ready to release, msn messenger was still in its prime

yeah no, ill stick with rapidly changing technologies rather than sticking to that for some misplaced sense of “stability”

[–] planish@sh.itjust.works 1 points 1 year ago

But one would like to be able to still play Half Life 2 today, even if Valve weren't helpfully around to update it. One would like to be able to read an old Word document or display an old blog post along with its scripts. So either you support the old standards and, for active content, the old APIs, or you lose access to anything that doesn't emit enough cash to pay a person to keep it current.

[–] pjhenry1216@kbin.social 5 points 1 year ago (1 children)

Did you just say progress is what's wrong with software development? Really. Do you even know how software development works before criticizing how it works?

[–] planish@sh.itjust.works 2 points 1 year ago (1 children)

I think the requirement for constant progress, and the expectation that all software be able to change arbitrarily with a year or so of notice, is in fact a problem with software development.

I do software development all the time, and I find this to be an impediment to my work. I also make the kind of breaking changes that cause this problem.

[–] pjhenry1216@kbin.social 2 points 1 year ago (1 children)

Is it difficult, sure. But not being easy doesn't mean its wrong. And the expectation is more to do with keeping a job. You can't just let your software go obsolete. And should software really be a cash cow where you write something once and you get paid forever? Doesn't feel right to me.

[–] planish@sh.itjust.works 3 points 1 year ago (1 children)

If you write a commercial program and sell it once, you are probably not going to be selling new copies in 10 years. If you keep getting paid you should indeed keep working. But if you stop working on it, it is better for the finished software to last longer.

Windows 11 has a "compatibility mode" that goes back to before XP. Android has a dialog that says that an old APK "needs to be updated", regardless of the continued existence of the original developer or whether the user is happy with the features and level of support.

It is this attitude of "we don't need to think about backward compatibility because we are powerful and all software has a developer on call to deal with our breaking changes" that causes software to go obsolete very quickly now. User needs also change over time, but not nearly as fast.

[–] pjhenry1216@kbin.social 1 points 1 year ago (1 children)

Compatibility mode is for software that isn't being supported anymore. It also is a huge security vulnerability. Android doesn't have it for a reason. Things usually fall out did too not updating the permissions to match the newer Android versions. That's a good thing. I'm tired of developers who don't consider security important.

And do you not agree with me? I'm confused. You're talking about continuous development being a good thing. Are you not suggesting that is something that costs money? I don't even know what your argument is anymore.

[–] planish@sh.itjust.works 1 points 1 year ago (1 children)

What's the security problem with Compatibility Mode? Is it just that it lets you let an app run with more permissions than it otherwise has on the new APIs? Or does it turn off a bunch of mitigations?

The Android permissions churn seems meant to protect people from applications: previously you could just say you need GPS, install, and then use GPS all the time. But untrustworthy apps started tracking people all the time, so Google declared that now only Google Maps is allowed to track people all the time, and that everybody else has to do a new location access ritual. If I have an old app that I trust (or wrote!) but doesn't do the ritual, I ought to be able to convey to the OS that I trust the application anyway. The machine works for me, not for Google's idea of what my privacy preferences are.

I don't see how a developer not implementing new permissions models is the developer not caring about security. I guess a more robustly sandboxed app is more secure than a less robustly sandboxed app? But just because a security enhancement like that is available doesn't mean it's actually worth doing, and the user experience of the new system (get sent to settings to toggle on file system access for a file manager) is often worse than before.

Having new development is better for the user than not; they will get features and improvements. But having to do development to prevent the user from losing features over time is a pure cost to the developer. The rate at which it currently happens makes it unnecessary hard to do projects that aren't shaped like commercial subscription services.

[–] pjhenry1216@kbin.social 1 points 1 year ago (1 children)

The permissions framework is a lot more than just claiming Google wants tracking all to itself. That's conspiracy level shit. The permissions framework has undergone immense changes from earlier ones from small things like giving an app an approximate location instead of detailed to also allowing permissions to be given at the time it's needed and to require asking every time. Did you even use older android? All the permissions were from the get-go and you had no idea how it was being used. Permissions are so much nicer and the sandboxing has evolved. Your understanding of permission changes is extremely naive and simple. Applications are much safer now than on earlier android. This is objective truth.
Compatibility mode basically means the runtime being used is a different one and any vulnerabilities that existed in that mode (not every one obviously) is now introduced. It's why Windows XP compatibility mode requires admin rights because it's entire authorization scheme was different and apps in that mode can do things that normally require elevated privileges. Microsoft recommends updating apps to not require compatibility mode for these very reasons. Even just the threat model alone is expanded due to the increased attack surface. I'm tired of developers who can't take security seriously.

[–] planish@sh.itjust.works 1 points 1 year ago (1 children)

I did use older Android, and I agree that the new permission model is absolutely much better for the use case of running apps that you do not trust or even like. I can scan a coupon with the camera today without having to worry that the store's app is going to be taking pictures of me tomorrow.

But that's hardly any of what I use my phone for. So I pay a lot of the costs of more hoops to jump through to allow stuff I actually want, while not really getting much of the benefit of being able to use malicious applications relatively safely.

And the one time I had a real permission problem, it was Snapchat trying to bully me into giving it access to all my files so it could "detect screenshots" before it would let me talk to my friends. And Android permissions were no help there, because the app can still tell if I reject its requests and won't get booted from the store for refusing to work until I grant access to everything, even though I do not want to.

The whole system seems to me to be designed to make people feel like their privacy is being protected, by popping up all the time to say that unused permissions have been removed and hey look at all these privacy options you have. It does indeed stop people from spying on your location and camera all the time without you noticing. But while the little permanent green dot is flashing every five minutes when your location is sent to Home Assistant like you explicitly asked, and you are trying to decide if you want to let Zoom use Bluetooth headsets just right now or on an ongoing basis, Google is hoping you don't notice that the OS and most of the apps are designed to extract value from you rather than to serve your interests.

It's now safer to run the evil apps, but they're still there trying to do evil.

[–] pjhenry1216@kbin.social 1 points 1 year ago (1 children)

I, uh, think your point is getting away from you here though, yeah? You can argue about the real intent (and we can pick and choose whatever OS you want), but the fact of the matter is OSes update for legitimate reasons and allowing older apps to run is expensive and/or insecure. App development does not and should never stop. Even Linux is patching vulnerabilities constantly. And new features do occur. Buying an app once is outdated in the connected age.

[–] planish@sh.itjust.works 1 points 1 year ago (1 children)

I understand that keeping backward compatibility forever isn't worth it. But I think it should be kept for longer than it is now.

[–] pjhenry1216@kbin.social 1 points 1 year ago

That's expensive. Increases the attack surface. Degrades performance by requiring more overhead. Bloats the size of the OS. Sure, you can care about backwards compatibility over all of that. But apps will likely continually get developed regardless of backwards compatibility. So there's still cost.

Again. I'm afraid you lost your point somewhere. Development rarely is ever completed. If it's truly "completed" then it's an extremely simple app with no real value and probably not worth anything. If it has value and isn't simple, then it can always be improved. So hosting isn't the only reason for ongoing payment. Continued development is extremely legitimate. Is it possible someone might abuse it? Sure. But software development never stops. It will always go into sustainment after release and when sustainment is over, the app is retired.

[–] Semi-Hemi-Demigod@kbin.social 5 points 1 year ago (1 children)

I think it started when software stopped being distributed physically. It's hard to push a bunch of updates to your users when they've need to physically have floppies sent to them versus doing it over the network.

I remember a time when software being "Gold Master" meant it was literally written to a gold master disk, from which copies were made. With that kind of release you had to make damn sure things were finished.

[–] NotAGoodUser@lemmy.world 2 points 1 year ago

The difference is that software nowadays is interconnected. Sync doesn't exist on its own, nor does Lemmy. And if one of these links changes, chances are, that something else needs to change to keep up. You're talking about standalone software that that exists entirely on its own. But that's not what this post is about.

[–] mojo@lemm.ee 3 points 1 year ago (1 children)

Technology moves fast. Why would you want to have an app that old, and what app is actually worth running that is that old and unsupported?

[–] planish@sh.itjust.works 1 points 1 year ago (1 children)

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.

[–] pjhenry1216@kbin.social 1 points 1 year 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.