Given the rate of change in OS and GUI environments, support libraries, and other APIs, most desktop apps don't work very well for long these days either.
Of course unlike SaS you can always continue to use an old version indefinitely in a VM if it really matters.
But I find the longevity of the vendor is still critical for supporting new environments and API requirements, and in practice I don't end up discounting the going-out-of-business risk much for desktop apps vs. SaS apps.
One of my biggest clients is a financial company whose core trading product is based on a commercial product they bought in the 70's (whose manufacturer subsequently went out of business in the 80's).
It's continued to run for 30 years, and they wouldn't dream of replacing it. I don't think they're an exception (although I suspect this is less true when you get out of the enterprise environment).
I should say here that I too have the 'old version' problem: The software to send samples to my Akai hardware sampler only runs on Windows 98. I have a Windows 98 PC just for this!
Maybe we need a web framework or platform that focuses on creating portable, trivially deployable applications. So that if the original site goes down, as long as it's open source, someone else can rehost it immediately (or you can just run it yourself from the start, if you know you will be depending on it) without having to spend time reconfiguring it. Server-side installs that are as easy as on the desktop.
The key point is "as long as it's open source", unfortunately most hosted services are not open sourced. If they were, we wouldn't need any special platform.
Yes but I think it's still a significant issue for open sourced web applications -- there's still room for improvement. It's usually a lot of extra work to make deployment on new systems completely automated, so developers don't bother. For my last Django project, I have a Fabric script that will deploy an update to the server with one command -- that was worthwhile overhead to invest time into, since it will continue to save me time. But I had little incentive to spend time on automating the initial deployment, since it's something I'll probably only do once, so doing it piecemeal by hand wasn't much of a problem.
I've seen projects where this kind of environmental coupling led to the developer not even bothering to open source their work, since they knew it would take too much for others to use the code.
It's usually a lot of extra work to make deployment on new systems completely automated, so developers don't bother.
Deprec + Capistrano makes this very close to a reality for Rails. It has some niggles -- like installing virtually everything from tarballs when I would strongly prefer it apt-get everything so that I could get updates and so paths and configuration files jelled well with what Ubuntu expects -- but it has been, and continues, to be a lifesaver for me in getting new projects up to speed.
You can also do one step deploys and automate a lot of cruftiness. (I can do upwards of forty deploys to my staging server in a day when in development mode on Twilio integration -- which is hard to test without actually having an accessible HTTP server and making phones actually ring -- so I have a script which commits my changes, tags a new staging release, and pushes it to the staging server in one command.)
Comments
The good thing about desktop software is if the vendor goes away, the software still works.
Not too keen (as a customer) on putting my time and effort into a SAAS hobby project that doesn't scale.
Given the rate of change in OS and GUI environments, support libraries, and other APIs, most desktop apps don't work very well for long these days either.
Of course unlike SaS you can always continue to use an old version indefinitely in a VM if it really matters.
But I find the longevity of the vendor is still critical for supporting new environments and API requirements, and in practice I don't end up discounting the going-out-of-business risk much for desktop apps vs. SaS apps.
One of my biggest clients is a financial company whose core trading product is based on a commercial product they bought in the 70's (whose manufacturer subsequently went out of business in the 80's).
It's continued to run for 30 years, and they wouldn't dream of replacing it. I don't think they're an exception (although I suspect this is less true when you get out of the enterprise environment).
I should say here that I too have the 'old version' problem: The software to send samples to my Akai hardware sampler only runs on Windows 98. I have a Windows 98 PC just for this!
But you can still run it, ultimately proving zandorg's point.
>The software to send samples to my Akai hardware sampler only runs on Windows 98. I have a Windows 98 PC just for this!
Doesn't it run under emulation, like virtualbox, or even in WINE98 or such?
It also runs on a Mac II vx, with System 7 and 32mb of RAM.
Maybe we need a web framework or platform that focuses on creating portable, trivially deployable applications. So that if the original site goes down, as long as it's open source, someone else can rehost it immediately (or you can just run it yourself from the start, if you know you will be depending on it) without having to spend time reconfiguring it. Server-side installs that are as easy as on the desktop.
The key point is "as long as it's open source", unfortunately most hosted services are not open sourced. If they were, we wouldn't need any special platform.
Yes but I think it's still a significant issue for open sourced web applications -- there's still room for improvement. It's usually a lot of extra work to make deployment on new systems completely automated, so developers don't bother. For my last Django project, I have a Fabric script that will deploy an update to the server with one command -- that was worthwhile overhead to invest time into, since it will continue to save me time. But I had little incentive to spend time on automating the initial deployment, since it's something I'll probably only do once, so doing it piecemeal by hand wasn't much of a problem.
I've seen projects where this kind of environmental coupling led to the developer not even bothering to open source their work, since they knew it would take too much for others to use the code.
It's usually a lot of extra work to make deployment on new systems completely automated, so developers don't bother.
Deprec + Capistrano makes this very close to a reality for Rails. It has some niggles -- like installing virtually everything from tarballs when I would strongly prefer it apt-get everything so that I could get updates and so paths and configuration files jelled well with what Ubuntu expects -- but it has been, and continues, to be a lifesaver for me in getting new projects up to speed.
You can also do one step deploys and automate a lot of cruftiness. (I can do upwards of forty deploys to my staging server in a day when in development mode on Twilio integration -- which is hard to test without actually having an accessible HTTP server and making phones actually ring -- so I have a script which commits my changes, tags a new staging release, and pushes it to the staging server in one command.)
Isn't that why virtualization was invented?