En novembre 2004, j’éditais un de mes premiers billets intitulé “Le paradoxe du calendrier”, faisant l’état des lieux des besoins en matière de gestion calendrier. Un lecteur m’ayant posé quelques questions à ce sujet par mail, je me propose aujourd’hui de refaire cet exercice aujourd’hui, soit 2 ans après (déjà !).

Version courte : la situation n’a malheureusement pas beaucoup changé (et c’est d’autant plus rageant !).

Passons donc à la version longue.

Ce qu’on peut noter, c’est que des standards ont quand même émergé dans ce domaine :

• CalDAV (basé sur Webdav)
• GroupDAV (soit disant une version plus simple de CalDAV)

Ma préférence va clairement à CalDAV qui est un véritable standard industriel, tandis que GroupDAV est une pseudo-norme élaborée par OpenGroupware.org. Oui, oui, le même OpenGroupware.org qui avait fait grand bruit à une certaine période, à grand coup d’effets d’annonce, et dont peu de personnes se souviennent encore aujourd’hui.

Et comme d’habitude dans le Logiciel Libre, on attend qu’il existe un standard avant d’implémenter un logiciel.

Alors, faisons un peu le tour des clients et serveurs implémentant CalDAV.
Serveurs :

• Darwin Calendar Server développé principalement par Apple et écrit en Python grâce au framework Twisted, dispo actuellement pour MacOS X Server (mais le logiciel étant à peu près portable, des versions pour FreeBSD et Linux sont en développement). Le logiciel est encore un peu jeune (il a été annoncé par Apple début août 2006)
• Hula développé principalement par Novell et écrit en langage C, dispo actuellement pour la plupart des Unix et Linux. Le logiciel n’est toujours pas sorti dans une version dite ‘stable’, bien que beaucoup de gens utilisent au jour le jour des versions de développement. Il dispose d’une interface web moderne (j’allais dire web2.0, mais Raphaël aurait râlé).
• Cosmo développé principalement par l’OSAF, écrit en langage Java. La version 0.4 est sortie récemment, et on attend pas de version 1.0 (feature complete et stable) avant plusieurs mois (pour ceux qui n’ont pas suivi, j’ai utilisé la même tournure il y a 2 ans, ce qui illustre bien le problème actuel). Il dispose lui aussi d’une interface web moderne.
• Bedework, basé sur UW Calendar, disponible actuellement en version stable. Le projet semble très orienté “université”. Il dispose lui aussi d’une interface web.

Clients :

• Evolution est originellement le client de groupware du bureau Gnome. Il a été porté il y a quelques mois sous Windows, mais ce port n’est pas supporté officiellement (bien qu’il existe des versions packagées)
• Chandler développé principalement par l’OSAF, écrit en langage Python. La version 0.7 est sortie récemment et est considérée comme une version “expérimentale” permettant de tester ce client avec le serveur Cosmo (sans garantie de fiabilité).
• Mozilla Sunbird / Mozilla Lightning développé par la Fondation Mozilla (bravo à ceux qui l’avaient déjà deviné). Sunbird est la partie gestion de calendrier ‘pure’, tandis que Lightning est un projet visant à intégrer Thunderbird et Sunbird, permettant ainsi d’avoir un véritable client de groupware. Les versions 0.3 sont sorties tout récemment, et ces projets sont loin d’avoir l’engouement de Firefox (ni son sex appeal).

Outils de migration :

• OpenConnector est un projet visant à offrir le support CalDAV au client de messagerie Outlook. Le projet roule aux donations, et, force est de constater qu’elles se font rares et que le projet avance donc lentement. La version actuelle est quasiment utilisable avec les serveurs cités ci-dessus, mais elle n’est pas du tout optimisée et peu testée.

Bref, une solution permettant de remplacer le combo Exchange/Outlook n’existe pas encore mais on s’en rapproche… tout… doucement… Mais, si par exemple, la version Windows de Evolution se révèle être d’assez bonne qualité pour une mise en production, le combo Hula + Evolution pourrait se révéler assez ravageur (il ne me manque plus qu’un client test pour valider tout ça :).

La question qui me turlupine le plus est celle-ci :pourquoi des grosses boîtes comme Red Hat ou Novell ne se sont pas attaqués sérieusement à ce marché qui est pourtant énorme ? Pour Novell, une réponse possible est qu’ils ont encore Groupwise en stock et qu’il faut le vendre aux clients. Mais pour Red Hat ?
Il est d’ailleurs assez clair que dès qu’une solution permettant de remplacer Evolution/Exchange fera surface, la ruée vers l’or va commencer.