ScheduleWorld shut down - R.I.P#
End of November, the scheduleworld.com service shut down. As a user [confirmed later](http://article.gmane.org/gmane.comp.mobile.syncevolution/1868), a notification had been sent earlier to paying customers. So the site is really gone and not just encountering some temporary problems. There does not seem to be any publicly accessible statement about the shutdown, hence this blog post. I have no information about the reasons for discontinuing the service. The notification to users did not give an explanation either. My guess is that the business side of the service did not work out. Syncing is a very challenging, technically difficult problem. I suspect that many users do not understand how much hard work goes into it and thus are less willing to pay for it. Then there is the competition with free services. If users are happy with online access Google Calendar, why should they bother paying for a synchronization service? There are reasons (see below), but perhaps not enough users care.
This is really sad, for several reasons.#
First, ScheduleWorld offered a technically superior SyncML implementation for calendar synchronization by supporting the full iCalendar 2.0 semantic, including [UID and RECURRENCE-ID](http://www.estamos.de/blog/2008/06/30/icalendar-20-detached-recurrences/). When describing these properties in 2008, I wrote that not supporting them “looks like a rather significant gap for SyncML-based calendar synchronization compared to proprietary solutions. Hopefully SyncML server vendors will wake up and do something about it…” I don’t think they have - or can anyone point to a SyncML server which supports this today, over one and a half year later? I’m not aware of any.
Second, although ScheduleWorld used the open source Funambol server code, none of the extensions or modifications were ever made available. That’s perfectly compliant with the license of the code that was used (GPL instead of AGPL as today), but it implies that the ScheduleWorld source code is now lost and no-one can use or study it. Third, I believe that storing my data on my own hardware and synchronizing it via open standards is crucial. ScheduleWorld made that possible for users who did not want to run their own SyncML server. With true syncing instead of just online access, data is available while offline - pretty obvious, but worth spelling out explicitly. When syncing is based on open standards, users can decide which service they want to use. They don’t depend on that service to store their data; important, because any service might go away unexpectedly and take the data with it. With ScheduleWorld, all data was always and by design also stored locally, so no data was lost when the site shut down. The same is not true for many (if not all) of the now popular Web 2.0 services.
Replacements for ScheduleWorld#
I’m not sure yet what I should recommend as replacement. Memotoo seems to be popular, but it does not support UID/RECURRENCE-ID semantic, so there are [issues when synchronizing complex iCalendar 2.0 calendar data](http://bugs.meego.com/show_bug.cgi?id=1180). For advanced users the [SyncEvolution server mode](http://syncevolution.org/development/http-server-howto) might be an alternative, but it is in a very rough state at this point and requires a publicly accessible machine for anytime, anywhere synchronization.