One of the difficulties for open source groupware products is interoperability with Microsoft's Outlook. A few products offer this as a proprietary add-on. What is Horde's direction here? Is the project looking to work with other open source products like OpenChange and Z-Push to facilitate more interoperability?
We embrace standards wholeheartedly so if Outlook supports them, great. But, of course, we're often asked for something like an Outlook connector. My answer usually is that instead of changing only the groupware back end to an open source solution, people would do themselves and their users a much larger favour in the long run if they switch to an open source ecosystem completely. This point of view might be different if we were backed by a larger company or had sales persons sitting in our necks, but at the moment we can afford the luxury of advocating open source software since we know it's the better alternative, at least in our area.
Nonetheless, we keep our eyes open and wouldn't reject contributed, or funded, support for commercial software. In the end we believe so much in our software that we won't refuse opportunities to gain broader adoption. And projects like Z-Push are definitely interesting solutions that we already have in the back of our heads – and in our request tracker so we don't forget about them. But we are much more keen on interoperability based on well established standards like CalDAV, iCalendar and SyncML.
One area Horde seems to be ahead of the curve (at least with open source groupware suites) is with synchronisation. It has a native SyncML server which has been tested with a few clients, including mobile devices. How much client compatibility is available and what is the next step for synchronisation? Will SyncML help solve a lot of the interoperability problems with open source groupware?
We track a user-contributed list of compatible clients in our wiki and the list is ever-growing. SyncML or DS (data synchronisation), as it's called these days, is a very complex standard, and accompanied by no less complicated standards for data formats. And like with any standard of such complexity there are several standard versions and dialects. Obviously we can't test every device and client software available. But the code is pretty stable now with the most popular phones and software clients, and it's getting more stable with every bit of user feedback.
SyncML can indeed be an alternative to interoperability problems and is one solution to use Outlook with Horde Groupware. But it's obviously not the same as direct client support through protocols like CalDAV, where changes on the client are reflected instantaneously on the server side.
A third alternative for using Horde along with desktop clients is to use both as clients to a Kolab server. Horde has been shipped with Kolab as the default Web client since Kolab version 2.2, and there are native clients that support Kolab systems, as well as connectors for Outlook.
When discussing Horde we need to consider that it's not just a groupware suite, but an entire framework with its own ecosystem of applications – from a wiki to bug tracking and task management. How is the ecosystem maturing, and how many apps does it have? What type of applications can we expect to see developed with Horde? And, what makes Horde attractive for developers?
I agree that this is one important "selling point", so to speak. Administrators managing a Horde installation can easily drop in any Horde application, and developers can create their own modules that integrate legacy systems or provide special functionality.
Unfortunately we don't get that much feedback from those developers as Horde just seems to work for them. People are surprising us all the more though, when every now and then they show what they created from Horde. Can you imagine a Horde application powering a set of huge billboards, for example?