La dépêche publiée récemment
https://linuxfr.org/2008/07/29/24355.html sur la suite office de Go-oo, l'alternative de Novell à
OpenOffice?.org, présente essentiellement le point de vue de Novell et plus particulièrement celui de Michael Meeks. DLFP a voulu avoir l'avis d'un responsable du projet
OpenOffice?.org. Sophie Gautier, ancienne responsable du projet francophone d'OOo et désormais simple membre de l'Advisory Board, et Jean-Baptiste Faure, nouveau responsable depuis le 25 juillet dernier (assisté de Laurent Godard).
Merci à tous ceux qui ont posé les questions. Leurs noms et contributions originales sont toujours disponibles sur la page de proposition de l'entretien :
https://linuxfr.org/interviews/8.html
Sur VCL et l'architecture d'OpenOffice?.org
DLFP :
Michael Meeks, dans l'interview de Der Standard, critique l'architecture technique d'OpenOffice? et disant que celle-ci n'a pas évolué (toolkit VCL Visual Class Library antédiluvien) et qu'il est difficile de faire de gros changements dans le code.
Est-ce que le projet pourra vraiment moderniser fondamentalement son code ou bien est-on condamné à des améliorations à la marge ?
Et quelle voie choisir pour moderniser le projet ?
- Améliorer le toolkit VCL (Visual Class Library)
- Abandonner VCL pour Qt/Java SWING/GTK+
- autre ...
Sophie Gautier : Bonjour,
VCL est effectivement une classe assez obsolète maintenant et la communauté (qui n'est pas seulement composée de Sun et Novell) travaille à un remplacement ou du moins une alternative. C'est long et cela prend du temps, OOo est un produit complexe qui fonctionne sur des systèmes d'exploitations variés et dans beaucoup de langues, notamment des langues à scripts complexes ou CJK.
Sur le Soutien de Sun et l'assignation de copyright
DLFP :
Sun est accusé de réduire le nombre de développeurs travaillant sur OOo.
Est-ce vrai ? Si oui quelles vont être les conséquences sur OOo et le projet pourra-il continuer à avancer ?
Sophie Gautier : La communauté
OpenOffice?.org regroupe plusieurs grands éditeurs : Sun, Novell, IBM,
RedHat?,
RedFlag? China, Ubuntu et un nombre important d'autres entreprises. Sun n'est donc pas seul à faire que ce produit existe, même s'il en est l'un des grands contributeurs. Même si Sun décide de réduire ses effectifs (ce dont je ne sais rien, le nombre réel de développeurs Sun travaillant à temps complet sur OOo n'ayant jamais été communiqué), la suite continuera à avancer. Comme le montre Michael Meeks, c'est un produit Open Source ;-)
DLFP :
Le fait de devoir assigner le copyright du code à Sun est souvent mal perçu par les contributeurs potentiels.
Est-ce que cela pose vraiment un problème à OOo ou pas ? Est-ce que Sun est susceptible de changer d'avis un jour ? Quel est votre avis sur cette question de l'assignation du code ?
Sophie Gautier : Nous sommes passés d'un Copyright Assigment (assignation du copyright à Sun) à un Joint Copyright Assigment (document écrit par la communauté et accepté par Sun qui partageait le copyright entre les parties) à, cette année, un Sun Contributor Agreement (partage de copyright avec respect de licences open source). Ceci s'est fait en accord avec la communauté et lors de la réunion de l'Advisory Board où cela a été proposé. Tous les éditeurs étaient présents et chacun était d'accord. La réalité d'un tel partage est en fait juridique pour une partie (et pour les pays concernés) : un recours devant une cours américaine nécessiterait la présence de plus de 50% des défenseurs. On peut alors comprendre pourquoi la plupart des grands projets open source ont un tel partage du copyright.
DLFP :
Faites-vous confiance à Sun sur le long terme (y compris en cas de changement de l'équipe dirigeante de Sun) ?
Sophie Gautier : Pour ce qui concerne la confiance faite à Sun, je pense qu'un tel projet ne peut fonctionner sans la confiance réciproque de ses contributeurs. Sun a toujours respecté ses engagements et même si tout n'est pas rose, qu'il y a parfois des lourdeurs, des lenteurs et des problèmes de communication, je ne l'ai jamais vu camper sur ses positions. L'équipe dirigeante de Sun a changé il y a deux ans (si mes souvenirs sont bons) et les orientations prises ont été plus favorables à notre projet, donc de ce côté je ne m'inquiète pas non plus. OOo est un produit qui représente des enjeux commerciaux importants, il faut y faire attention quand on est un contributeur bénévole, mais cela ne doit pas empêcher la communauté de faire avancer ce projet, tant dans sa gouvernance que dans sa production. Et nous devons pouvoir faire confiance tant à Sun qu'à Novell ou IBM, etc.
Sur le projet Go-oo
DLFP :
Comment voyez-vous le projet Go-oo ? Est-ce pour vous une alternative crédible ? Un fork menaçant ? Un concurrent négligeable ?
Sophie Gautier : Go-oo existe depuis longtemps et vit à côté de la communauté tranquillement. C'est un espace où chacun peut committer rapidement et qui n'a pas les contraintes que peut avoir un produit comme
OpenOffice?.org qui souhaite répondre à un environnement industriel. Go-oo ne s'occupe ni d'assurance qualité, ni de localisation. Ce qui pour nos projets en langue native (comme fr.openoffice.org ou de.openoffice.org) est un gage de crédibilité et de confiance auprès de nos utilisateurs.
Pour prendre l'exemple de la version francophone, celle-ci est contrôlée par une équipe d'une vingtaine de testeurs et ne peut être distribuée si le responsable de cette équipe ne l'a pas validée au préalable. De même un menu en anglais ou une fonctionnalité en anglais dans l'interface stoppera la distribution de la version. C'est à cette qualité qu'
OpenOffice?.org s'attache quitte à mettre plus de temps à intégrer certains patchs. Pour moi, il n'y a pas de concurrence entre Go-oo et OOo, ces espaces ont des destinations et des expressions différentes. Que Michael le revendique comme une communauté et menace de forker n'est pas nouveau d'ailleurs :-)
Jean-Baptiste Faure : Mon point de vue n'est pas ici celui d'un développeur puisque je ne produis pas de code pour OOo. En tant que membres de la communauté francophone de
OpenOffice?.org nous subissons ce qui ressemble beaucoup a des guerres commerciales et ce n'est pas satisfaisant. Concernant go-oo je veux m'en tenir aux faits :
- go-oo nous parle de correction rapide des bugs : sur le site de go-oo les derniers builds de la version "unstable" qui préfigure la prochaine 3.0 ont 2 mois. Comme rapidité on fait mieux. Durant ces 2 mois, il y a eu 2 versions bêta et une quinzaine de snapshots pour OOo, testables par tout un chacun.
- go-oo critique la lourdeur du processus de développement de OOo. Sans doute mais quand je lis sur http://go-oo.org/ qu'on peut apporter du code à go-oo sans spécification, je suis perplexe. Et je ne crois pas que ce soit propre à emporter la confiance de grandes organisations qui envisagent de migrer vers OOo.
Au bout du compte ce sont les résultats qui comptent :
- la version Go-oo est celle qui est incluse dans Ubuntu et d'autres distributions et elle fonctionne plutôt moins bien que la version officielle même si elle est mieux intégrée au système.
- la version officielle est développée selon un processus lourd et frustrant par bien des aspects. Mais elle passe par les étapes Localisation et Assurance Qualité et ça c'est irremplaçable, en particulier dans un cadre professionnel. Et ce travail, au moins aussi important que l'interopérabilité avec les formats Microsoft, est essentiellement réalisé par les communautés linguistiques. Ce qui emporte la confiance de l'utilisateur en OOo ce sont ses communautés linguistiques, avec le support qu'elles apportent, les tests d'assurance qualité des versions localisées et la rédaction et la mise à disposition de documentation (guides, tutoriels, etc.). Tout cela dans la langue de l'utilisateur. Ce serait bien si go-oo était plus présent sur ce terrain.
Sur le développement et les tests
DLFP :
Michael Meeks cite une anecdote à propos du quickstarter. Celui-ci a été amélioré par Novell qui a envoyé son patch à OOo. Sun a corrigé un problème mais, ce faisant, a provoqué un bug dans GTK+ qui empêche la compilation.
Selon lui Sun ne teste pas la version GTK+ (celle utilisé sous Linux) : "Sun (...) broke the GTK+build again which they clearly didn't test themselves".
Est-ce vrai que la version GTK+ est le parent pauvre des versions OOo ? Quel est l'importance respective des tests sur la version Windows et des tests sur la version Linux ? Est-ce que la version Linux est une version un peu au rabais ou pas ?
Sophie Gautier : On pourrait déterrer qui a cassé quoi dans les dernières versions, mais à quoi cela avance-t-il ? Les listes sont pleines de bugs rencontrés sur les versions compilés à partir de Go-oo, il faut donc les jeter et le travail des contributeurs avec ? Je ne suis pas de cet avis.
Je ne vais pas décrire ici le process de développement en continue et les outils mis en place, les patch sont testés sur toutes les versions, si ce n'est pas par Sun, c'est par la communauté. D'autres versions sont compilées dans des environnements différents de celui de Sun et sont testés également. La version .deb fournie par le projet francophone pendant un long moment n'a pas été compilée par Sun mais par Pavel Janick. Et elle était testée de la même façon que les autres pour pouvoir être distribuée. D'ailleurs vous ne parlez pas de Mac et nous avons aussi besoin de testeurs sur Mac :-). Il est évident que l'on peut toujours faire mieux et je crois que nous en sommes tous conscients, mais on ne peut vraiment pas dire que la version Linux est une version au rabais ou alors, elles le sont toutes !
DLFP :
Combien de développeurs travaillent régulièrement sur OpenOffice?.org et combien parmi eux sont des développeurs SUN ? Quels sont les principaux contributeurs en dehors de SUN ?
Combien de devs supplémentaires faudraient-ils à votre avis pour que OpenOffice?.org puisse être "dépoussiéré" et que le développement avance à une vitesse satisfaisante (i.e correction des bugs, ajouts de fonctionnalités, etc.) ?
Jean-Baptiste Faure : Chaque développeur supplémentaire est nécessaire. Et plus il y en aura dans la communauté plus celle-ci pourra peser sur l'avenir de OOo. Voir par exemple la réponse d'Éric Bachard sur la dépêche d'origine. Mais nous avons aussi besoin de testeurs. Ainsi la version 2.4.1 francophone n'a pu être publiée pour
MacOS? faute d'avoir pu réunir une équipe de test suffisante. Ce qui est désolant car je suis sûr que cette version, restée à l'état de RC, est de grande qualité.
Sophie Gautier : Difficile de répondre à cette question, il doit y avoir *environ* 150 développeurs qui travaillent à plein temps sur OOo. Si l'on totalise des estimations (donc un chiffre non sûr) on pourrait dire qu'il y a plus de 70 développeurs Sun, environ 20 chez Novell, peut-être plus de 50 chez
RedFlag?. IBM a annoncé 35 développeurs, Canonical 1 développeur,
RedHat? peu également. Google et Intel ne contribuent plus. Certaines entreprises contribuent également, mais je ne connais pas le nombre d'employés. Et il faut bien sûr ajouter les développeurs bénévoles.
En fait il manque des contributeurs un peu partout. A l'heure actuelle, il y a environ 1300 "issues" ouvertes qui attendent d'être confirmées, il faut donc des contributeurs à ce niveau. Il en faut ensuite pour les corriger, puis pour tester ces corrections. Et puis dans le même temps il faut faire évoluer le produit, construire ce que sera une suite bureautique dans l'avenir, rédiger le concept et là encore il manque du monde. Il manque également du monde pour les petites tâches du quotidien de la communauté, maintenance des sites et du wiki, modération des listes, etc.
C'est une grande communauté, qui demande un peu de temps avant d'être appréhendée, mais qui reste très accueillante et conviviale :-)
Sur Lotus Symphony
DLFP :
Y a-t'il une chance de voir certaines fonctionnalités de Lotus Symphony dans les prochaines version OOo (surtout niveau interface graphique) ? Comment la communauté voit cette suite bureautique ? un concurrent ou un allié ?
Jean-Baptiste Faure : Il y a toujours une chance, ou un risque ;-).
OOo est un logiciel libre, il suffit donc que des développeurs avec de bons arguments soient intéressés et prêts à s'investir dans de tels développements. À quelles fonctionnalités particulières pensez-vous ? Pour le moment je n'ai pas trouvé de demande d'amélioration faisant référence à Lotus Symphony.