Why is Spanning Sync a Service?

I’ve been subscribed to the Spanning Sync blog for a little while now, monitoring the progress they are making in their iCal to Google Calendar sync solution. Yesterday they released their first public beta – then quickly had to shut it down again.

Frankly, I don’t understand why they choose to implement this as a service in the first place. Any gain they may have achieved by leveraging existing platform code they had written for SalesForce is negated by having to maintain servers, losing customers that don’t want to pay a monthly fee and leaving the door wide open for other developers to build a direct iCal to GCal sync.

If they choose to add syncing to other web services in the future as they note in their explanation, they can add on a service component as an optional upgrade at that time for those who want it. Doing it that way would also drastically reduce the hardware needs for their service portion – it could grow organically instead of just opening the flood gates and having to shut it down.

I’ve got no problem paying for software or for services, but this doesn’t make sense to me. I don’t need a service to sync iCal to GCal – a stand-alone app/iSync conduit would work fine. I’m certainly not going to pay a subscription to add more points of failure to something that is likely to be somewhat fragile in the first place.

Something that should have been a huge hit for both their customers and them as a $25 stand-alone utility is now likely to be a constant maintenance hassle for both.

Maybe I’m missing something fundamental here – if so, enlighten me in the comments.