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.
I agree, I’d prefer to a have utility on my own system that took care of the syncing for me.
Yeah, you’re right. It’s a good idea gone bad.
I agree, I too would rather have a utility, not a service. It makes more sense. I haven’t been following the project, but when I read about it being public I hoped on it. I was shocked that they would haver server issues and I had no clue it was to be a “service.”
Beyond the fact that it doesn’t seem necessary, there’s something that doesn’t seem right about a “for-profit” business plan built around a free service (GCal).
I was one of the “few” that got through yesterday and it works extremely well. My problem, the fact that they now have my google username and password. It’s makes my stomach turn. Just another reason for it to be a client side app rather then a service oriented spp that could potentially be a harvester.
I’m with you here Alex. I was really intrigued by, and watched closely, the development of SS. Unfortunately it is looking more and more like something I don’t want to use. It’s a great idea though, and I still don’t get why we haven’t seen an iCal plugin to sync with GCal. Heck, Flickr and Picasa both have plugins for iPhoto exporting…
A friend postulated that perhaps they were doing this to keep a consistent revenue stream instead of just one-off purchases. That could be, but the trade-off is huge.
Besides, sync is hard. Scaling a web service is hard. Doing both at once… not something I’d want to be responsible for. 🙂
..and to make matters worse, I found this wonderful feature, which is why I highly advise against:
http://www.faithstor[...]anning-sync/
Alex,
The decision to make our sync engine server-based certainly puts a heavier burden on our shoulders. We have to make sure the service scales, and is available, and is secure. But it also opens up an array of possibilities for providing sync services between other hosted services–think Salesforce.com and Google Calendar–that simply wouldn’t be possible if we built the engine into any one client platform.
You’re right–sync is hard, and building scalable web services is hard. But we’re not afraid of hard work, and we think the end result is going to be very valuable to a lot of people.
Regards,
Charlie
spanningsync.com
I’ve posted a more detailed discussion of this issue here:
http://groups.google[...]7d7d7010acc4
and added a link to our FAQ at
http://spanningsync.com/faq
Regards,
Charlie
spanningsync.com
gSync is a small utility that does sync without any 3rd party in between…and oonce we are out of beta (soon….few weeks) it will be a one off utility bit of software price.
also since we have integrated Apple’s own SyncServices we have a clear integration path to other sync processes…gives us lots of opps for neat functionality.
http://www.macness.com
cheers, Jim Fuller
[…] was initially critical of Spanning Sync1. I still think this would be better as an application than a service, but […]