Resistance is futile. You will become a file server.
On the gaspingly sfumatoed [1] canvas on which web history is being recorded today, in real time, I have spotted a pattern. A pattern hitherto unseen by me but which is now glaringly obvious to me. The pattern is a simple repeating pattern of four events:
Event 1: A web-based consumer service is conceived in which users sign up for accounts and then get to upload/download digital data to/from the web from any computer they have access to. (The exact nature of the service is irrelevant from the point of view of the overall pattern.)
Event 2: Two seconds after the service is launched, its developers notice that some 'users' are in fact bots. Programs that have been developed to bypass the interactive aspects of the site.
Event 3: After much gnashing of teeth and re-thinking of business models, version 2 of the service is launched with an API. This provides a formal mechanism that allows developers to interact with the service through bespoke software. That is, end-users can upload/download data without having to go anywhere near the website of the service provider.
Event 4: Two seconds after that, some bright spark, somewhere uses the published API to make the service appear like just another file system. Users can load up the service into their desktop environments and drag/drop files just like they would to their local hard disks.
Two examples of this from recent history now. I think I first became conscious of the pattern with GmailFS [2]. What a delicious idea! Treat your GMail [3] account as a regular data store. A short while ago I came across FlickrFS[4] which takes a similar tack using the storage facilities of Flickr [5].
It seems that if a web service can, in any reasonable way, be treated as a repository of files, someone, somewhere will find a way to turn the web service into a file system.
The reason I think this pattern is important is that new service developers would do well to factor it into their thinking. If, for example, your business model is eyeball-oriented (you need to drive traffic to a site/application that you control), the file system pattern may thwart your plans. By the time your service has been boiled down to a network file system, the eyeballs are no longer gazing at your content.
You could of course, scatter the digital equivalents of thumbtacks on the carpet and try to thwart the use of the file system pattern on your service. The risk here is that users will take their eyeballs and move elsewhere. Perhaps it may be better to skip straight to event 4, embrace the reality of the file system pattern by implementing it yourself. Then, seek a business model that can work with, rather than fight against, the file-system-ification of your service. Resistance is most likely futile.
[1] http://en.wikipedia.org/wiki/Sfumato
[2] http://richard.jones.name/google-hacks/gmail-filesystem/gmail-filesystem.html
[4] http://www.boingboing.net/2005/11/07/flickrfs_post_your_p.html