|
There are a lot of interesting (and untested) issues and concerns here. One that I worry about is what happens when the service disappears. A frequently touted virtue of conventional open-source software is that source code access provides an insurance policy against a vanishing vendor. With sufficient expertise (which may be difficult or expensive to gain), a client company can continue to maintain and/or upgrade a software package even if the original vendor is no more.
With a Web Service, this is a more difficult proposition. If SomeFreeWebBasedEmailProvider.Com decides to shut down tomorrow, what practical or legal recourse do users have to get at their saved messages, let alone have mail forwarded to a new place? Creditors, lawyers, and the IRS all have a legally mandated place in the money queue when a company goes bankrupt. Is it time to introduce the idea of a "data creditor" who has certain rights when a company goes belly up?
As pointed out in the weblog entry, this is an even more difficult proposition when the value of the one user's data is integrated with other databases. My e-mail living on a remote server is a relatively self-contained chunk of stuff. A list of "favorite locations" or point-to-point driving directions on a mapping site, or an Amazon-style wishlist or favorites list are a little less easily exported. A list of places could be keyed to longitude/latitude, and a wishlist (for books) to ISBN, so there is some externally referenced standard that would let you make sense of the data.
This is harder when the user data is even more ill defined. When I was CTO at TVGrid.Com, users stored lots of television-related preference data on our servers, such as shows they had recorded, wanted to receive reminders for, had rated, or other attributes. There's no ISBN for television programs, which means that even if we were able to provide users with a way to download their account data when we went away, they wouldn't have much use for it.
Maybe there is a business model here for user data escrow.
|
