Hacker News Reader

Comment by bmelton | Hacker News Reader

I'm sure he just means that on the web, the turnaround from bug to bugfix to patched instance is near instantaneous.

Step 1, Notice bug

Step 2, Fix bug

Step 3, Deploy bugfix

The steps between 1 and 2 could obviously take a variable amount of time, but Step 3 is 'near instantaneous' on the web. The thought of having to relinquish deployment to somebody else, and that somebody else possibly taking a week to just alert users that there IS a bug fix, much less the time it takes for those users to see and apply the fix, that's a relative eternity.

View on HN

True, but surely you can retain the ability to alert or otherwise communicate these things to your users without putting any of the main GUI in a web view? Minor bugs require only a little communication and major show-stoppers can be avoided with care.

Maybe I'm a little biased on this, but I hate that a web app I might be relying on can change completely (both in GUI and functionality) without my consent or involvement; at least with app updates I can get some warning and release notes -- a chance to extract my data before taking the plunge... but I guess I'm getting a bit off-topic.

As an 'app owner', it perhaps benefits you to possess the ability to preserve what you've paid for. In some cases, I'm sure this actually is a benefit, as in the times updates are negative, or take away functionality or change the way they do things. In most cases though, it just means that you aren't up to date with what is current, which may or may not be a bad thing.

It is offtopic, but still interesting. One supposes that is the reason why apps cost a set amount of money (usually) while web apps are usually a subscription model. That is of course questionable when the app uses web views to your server, as those customers always cost you money so long as they're using the app vs. standalone apps (like games and the like) where you truly are making a one-time purchase.

Strictly speaking, none of us "own" the majority of the software we pay for. We license it, and we are entirely at the mercy at the vendor's terms, with the only recourse being not buying it in the first place.

It's yet another area where the nature of software and the networked world breaks our object-oriented intuitions in ways we're still trying to resolve in the social contract.

I get the implication, and while that wasn't the point I was making, the purchase of a self-contained app from the app store is essentially the same thing as owning the app.

You've exchanged money for a good, and as the app owner there aren't any readily available means of getting the good back from the owner should you disapprove of how they're using it, just like it would be with a tangible good. Obviously copyright still stays in effect so their ability to copy, resell, yadda yadda are still restricted, but otherwise it's theirs.

That said, in this day and age, fewer and fewer apps are completely self-contained, and/or work without being plugged in to something, so it's effectively a moot point.

Weigh that against a critical bug appearing and having your app be useless for a week while awaiting an already-completed update.

At the same time, I understand your feelings about wanting to be in control of updates. (As a user, I'm even upset that Apple doesn't allow the user to roll back.) But when devs can count on every user being up to date, it enables them to push new features more quickly instead of having to write backwards compatibility, fallbacks, etc.

The question of who owns and controls code is a sticky one, and I'm not sure there's an ideal answer; to the extent that there is, I think it varies highly by the nature of the app.

Reply on news.ycombinator.com