Apart from another dumb name from Apple (“MacBook Pro”), the underwhelming announcements in the most recent MacWorld keynote hid a really cool idea that could have changed how people used computers, had it not been saddled with an extremely irritating and unnecessary limitation. The new edition of iPhoto has a feature called (somewhat unimaginatively) “photocasting”. It allows you to upload a photo album to a server, and provides an RSS feed to which others can subscribe. If they also have iPhoto, it wraps around the RSS feed and opens the album like any other iPhoto album. Instant, easy image sharing for the masses. They don’t need to know how it works, it just does.
This is a cool idea largely because it helps eradicate one of the more unpleasant abuses of technology: e-mail attachments. There are a number of free and easy ways to move files from one person to another. Attaching them to an e-mail is one of the worst of them. It works, but it really isn’t what e-mail systems were built for. This method survives, even prospers, because most people don’t know any better. The photocasting system avoids the main drawbacks of e-mail file transfer: maybe you really don’t want that 50 megabytes of pictures from grandma to fill up your inbox and make the rest of your mail bounce. Maybe you don’t want to spend the download time it will take to grab all this data you don’t want, just to read your e-mail. Maybe there shouldn’t be separate copies of this data stored individually in the dozens mail queues that grandma cc’d on the message. By easily creating a single copy of the data in a semi-public spot and mailing a reference to this data, this data is no longer shoved down at you, putting you in control of if you want it or not. By making it seamless, Apple brings this solution to the masses.
Problem: Apple’s implementation of this idea requires the possession and use of their subscription .Mac service, which means that the masses will never use this idea enough to allow it to supplant e-mail attachments as the photo-sharing mechanism of choice. Had the whole system been made an open standard that could be published to any web server, the majority of the planet would be sharing photos this way within a year. By tying it to a service that most do not use and only Apple provides, this great idea will languish.
Well, perhaps not. The one saving grace is that Apple chose to use an RSS feed. Since RSS is an open standard, it’s likely that enterprising souls will release “iPhoto album readers” on various platforms, so at least the “viewing” half of the system might catch on. No doubt people will build software to upload a bunch of pictures to your own server and publish a compatible RSS feed for them. This will be useful, but you won’t be able to do it from iPhoto, which will suck.
The .Mac service, while somewhat interesting, is completely useless to me because I own my own web domain (for not much more than a .Mac subscription). The service would only be compelling to me if one or more of the following happened:
- Apple combines the two products they obviously consider to be yearly costs (iLife and .Mac) into a bundle that costs much less than the two combined. That is, offer an iLife + .Mac yearly subscription for $100 or so. This, I suppose, would be the equivalent of giving away iLife with a .Mac subscription.
- Someone built an open source clone of the .Mac system that I could run on my own server. It may be that such a project already exists, but Google’s insistence on ignoring the dot in “.Mac” make searches for it problematic. (If anyone is interested in starting such a project, I think a great name would be “!Mac”, pronounced “not Mac”.)
- .Mac is changed to provide domain hosting services, with corresponding flexibility for installing blog software, etc. I’m not holding my breath for this.
I’m sure Apple is thinking that keeping the system closed like this will bring them more revenue. I’m also sure that making these neat ideas open would bring them even more.
Update: There is now a surprising amount of foaming at the mouth about how well or badly Apple uses RSS. Sam Ruby wades through it.