I'll go out on a limb and declare the proposed scheme wacky. Why? It ignores so much of the way software brings value to my life.
Let's take Mint.com as an example. One could certainly build a Quicken-style application with the Unhosted platform which would perform its processing on the browser but save all data to a server in an encrypted form. Users would be able to access their data from any browser. What's broken is that a core part of Mint's value proposition is that it watches out for you and proactively tells you important stuff. Did you know that your credit card bill is due tomorrow? Mint.com sends you an email. If Mint.com did not have unencrypted access to your data, it could not provide you with this service. You would be back in the dark ages of Quicken when you had to remember to use the application to get such information.
The in-the-cloud services which provide the most value to me could not exist without being able to process my data in the background. A more interesting idea to consider is whether the ownership of the hosted software could be decoupled from the hosting provider. There seem to be a few open source projects out there which aim to provide AppEngine-like frameworks which could allow hosting of one's application as-is by a bunch of cloud hosting services. Think AppEngine with choices. What if someone produced an open source, GMail-like appliance bundle built for one of these frameworks? It could be deployed by an individual/company/whatever to a hosting provider's cloud. Included in the project would be easy ways to migrate from to another hosting provider, data export, etc.
Although such solutions would solve the background processing requirement problem, they would still require me to think about my email platform. Is it time to upgrade? Which provider should I use? Etc, etc. The likely market outcome would be that hosting providers would offer "managed" hosting of these open source appliances. What's the difference between this state of affairs and the current GMail/Hotmail/etc. landscape? Probably little more than an open standard for data interchange along with an easy way to export one's data.
The problem with such SaaS concerns is the same as with Java in 2004 when Stallman wrote about "the Java trap". Most people (me included) saw Sun as a benevolent dictator and didn't worry much about what could go wrong. Now that we've witnessed Oracle's apparent power, we know to be afraid. Perhaps there are some small examples of SaaS gone awry, but it's not like SalesForce.com has doubled its prices and throttled data export to keep users from running.
Today, no one thinks to demand complete data export capabilities along with a contractual agreement to continue to provide them. What if customer demand made such features commonplace? An upstart Mint.com competitor could offer Mint.com data import to reduce switching costs. Would such a state of affairs appease the majority of SaaS lock-in concerns?
I personally don't see what all the fuss is about. Whenever humans work together in any form to better their lives, they give up some control and risk that others will not act in their interests. The risk and uncertainty are a matter of degree rather than kind. The guy who plows my driveway could decide to run off to Vegas, and I wouldn't know until the next major snowfall. Wouldn't I be better off to operate my own plow so that I have the control? By this same logic, I would be better off running my own servers and maintaining my own applications. With the snowplow guy, the magnitude of my risk is capped -- if he doesn't show up, I can call up a competitor and have him take over the contract. Similarly, smart humans assess the risk of trusting others and make sure that their agreements do not provide too much power to the counter-party. The issue is that we as humans have learned over time what kinds of risks are inherent in various sorts of transactions, and the invisible hand has responded with defacto standards for agreements which constrain these risks to acceptable levels. It is that SaaS is so new that most people are unable to assess the risks of various offerings, so those which transfer power to the provider in extreme ways are not so obviously evil.
I disagree that this idea is incompatible with this usage profile. You could have your personal computer do alert processing on the box itself, and either setup a system of unencrypted alert messages, or have it ping you every once in a while.
The main idea here is to only allow your personal information off of your own computer in an encrypted form. This seems like a pretty good place to aim for in the future.
The problem isn't lock-in as much as it is privacy. It is better for consumers for all of their private data to be private as they use the internet, instead of having the rely on trusting someone else with the data. Part of the concern is lockin - as in what happens if the service changes their policies or disappears. But this is not the whole picture
As far as your mint.com example goes, such notification could still be provided without the server knowing that your credit card bill is due tomorrow. The client can tell mint.com when notice is due, and provide an encrypted blob of data to be sent as the notice. Essentially mint.com would just need to provide a cron service to the client.
When I thought of this example, I had imagined Mint.com querying my credit card company to ask what the due date was and whether or not I had already paid the bill.
>Mint.com sends you an email. If Mint.com did not have unencrypted access to your data, it could not provide you with this service.
That's a terrible example. If this is your primary argument for web services, then they've been obsolete since cron came with UNIX V7 in 1979.
On Mac OS X, without even running the app, iCal has no problem sending me an email to notify me of an upcoming event. How does it accomplish this magical feat? It runs a background process that just happens to have access to my local calendar database, because it's already on my computer.
>The in-the-cloud services which provide the most value to me could not exist without being able to process my data in the background.
And you would have a very difficult time actually using those services without access to a personal computer that already has far more resources at hand to do the same processing itself.
Yes, and your local computer must be on, the software must be running, etc. Want that email delivered to your phone, your work computer, etc.? My example is hardly the best one, but it was simple and commonly understood.
If you don't turn your computer on at least once a day, then chances are you aren't reading your email on it.
Run your calendar/bill-reminder software on the machine you use the most (which you'd do naturally, anyway) — whether it be your phone, your laptop, or wherever — and the justification for remote hosting collapses.
Unless you're away from your usual location for a couple of weeks, in which case this type of remote hosting is pretty darn useful (unless your primary computer is your smartphone, but not everyone has one).
Comments
I'll go out on a limb and declare the proposed scheme wacky. Why? It ignores so much of the way software brings value to my life.
Let's take Mint.com as an example. One could certainly build a Quicken-style application with the Unhosted platform which would perform its processing on the browser but save all data to a server in an encrypted form. Users would be able to access their data from any browser. What's broken is that a core part of Mint's value proposition is that it watches out for you and proactively tells you important stuff. Did you know that your credit card bill is due tomorrow? Mint.com sends you an email. If Mint.com did not have unencrypted access to your data, it could not provide you with this service. You would be back in the dark ages of Quicken when you had to remember to use the application to get such information.
The in-the-cloud services which provide the most value to me could not exist without being able to process my data in the background. A more interesting idea to consider is whether the ownership of the hosted software could be decoupled from the hosting provider. There seem to be a few open source projects out there which aim to provide AppEngine-like frameworks which could allow hosting of one's application as-is by a bunch of cloud hosting services. Think AppEngine with choices. What if someone produced an open source, GMail-like appliance bundle built for one of these frameworks? It could be deployed by an individual/company/whatever to a hosting provider's cloud. Included in the project would be easy ways to migrate from to another hosting provider, data export, etc.
Although such solutions would solve the background processing requirement problem, they would still require me to think about my email platform. Is it time to upgrade? Which provider should I use? Etc, etc. The likely market outcome would be that hosting providers would offer "managed" hosting of these open source appliances. What's the difference between this state of affairs and the current GMail/Hotmail/etc. landscape? Probably little more than an open standard for data interchange along with an easy way to export one's data.
The problem with such SaaS concerns is the same as with Java in 2004 when Stallman wrote about "the Java trap". Most people (me included) saw Sun as a benevolent dictator and didn't worry much about what could go wrong. Now that we've witnessed Oracle's apparent power, we know to be afraid. Perhaps there are some small examples of SaaS gone awry, but it's not like SalesForce.com has doubled its prices and throttled data export to keep users from running.
Today, no one thinks to demand complete data export capabilities along with a contractual agreement to continue to provide them. What if customer demand made such features commonplace? An upstart Mint.com competitor could offer Mint.com data import to reduce switching costs. Would such a state of affairs appease the majority of SaaS lock-in concerns?
I personally don't see what all the fuss is about. Whenever humans work together in any form to better their lives, they give up some control and risk that others will not act in their interests. The risk and uncertainty are a matter of degree rather than kind. The guy who plows my driveway could decide to run off to Vegas, and I wouldn't know until the next major snowfall. Wouldn't I be better off to operate my own plow so that I have the control? By this same logic, I would be better off running my own servers and maintaining my own applications. With the snowplow guy, the magnitude of my risk is capped -- if he doesn't show up, I can call up a competitor and have him take over the contract. Similarly, smart humans assess the risk of trusting others and make sure that their agreements do not provide too much power to the counter-party. The issue is that we as humans have learned over time what kinds of risks are inherent in various sorts of transactions, and the invisible hand has responded with defacto standards for agreements which constrain these risks to acceptable levels. It is that SaaS is so new that most people are unable to assess the risks of various offerings, so those which transfer power to the provider in extreme ways are not so obviously evil.
I disagree that this idea is incompatible with this usage profile. You could have your personal computer do alert processing on the box itself, and either setup a system of unencrypted alert messages, or have it ping you every once in a while.
The main idea here is to only allow your personal information off of your own computer in an encrypted form. This seems like a pretty good place to aim for in the future.
The problem isn't lock-in as much as it is privacy. It is better for consumers for all of their private data to be private as they use the internet, instead of having the rely on trusting someone else with the data. Part of the concern is lockin - as in what happens if the service changes their policies or disappears. But this is not the whole picture
As far as your mint.com example goes, such notification could still be provided without the server knowing that your credit card bill is due tomorrow. The client can tell mint.com when notice is due, and provide an encrypted blob of data to be sent as the notice. Essentially mint.com would just need to provide a cron service to the client.
When I thought of this example, I had imagined Mint.com querying my credit card company to ask what the due date was and whether or not I had already paid the bill.
>Mint.com sends you an email. If Mint.com did not have unencrypted access to your data, it could not provide you with this service.
That's a terrible example. If this is your primary argument for web services, then they've been obsolete since cron came with UNIX V7 in 1979.
On Mac OS X, without even running the app, iCal has no problem sending me an email to notify me of an upcoming event. How does it accomplish this magical feat? It runs a background process that just happens to have access to my local calendar database, because it's already on my computer.
>The in-the-cloud services which provide the most value to me could not exist without being able to process my data in the background.
And you would have a very difficult time actually using those services without access to a personal computer that already has far more resources at hand to do the same processing itself.
Yes, and your local computer must be on, the software must be running, etc. Want that email delivered to your phone, your work computer, etc.? My example is hardly the best one, but it was simple and commonly understood.
Yes, many apps will benefit from an always-on server. Must we rely on a Mega Corp just for some strange desire to turn everything off?
If you don't turn your computer on at least once a day, then chances are you aren't reading your email on it.
Run your calendar/bill-reminder software on the machine you use the most (which you'd do naturally, anyway) — whether it be your phone, your laptop, or wherever — and the justification for remote hosting collapses.
Unless you're away from your usual location for a couple of weeks, in which case this type of remote hosting is pretty darn useful (unless your primary computer is your smartphone, but not everyone has one).