C'est assez logique. Que la version Apache Open Office évolue moins vite que Libre Office n'est pas un problème, ce pourrait même être un avantage en entreprise où on a tendance au conservatisme. Mais qu'on en arrive à ne même plus avoir assez de ressources pour corriger les bugs, à un moment ça devenait inévitable.
Je l'avais déjà dit dans la discussion de l'an dernier: oui à l'existence de deux suites à condition qu'elles prennent des directions suffisamment différentes pour que chacune ait un segment de marché facilement défendable. J'ai vu passer un peu plus tard la réponse d'Apache qui disait qu'ils étaient en désaccord avec certains choix faits par Libre Office.... mais tout en s'abstenant de dire lesquels, ce qui ressemble bien à une simple querelle de personnes.
Sincèrement, il y avait foule de possibilités: alléger le code pour créer une alternative plus légère (Libre Office c'est quand même un peu gros pour un cd live); se concentrer sur le portage vers une autre plate-forme (Android?).
Ou plus simplement transformer la suite en librairie: dans mes projets professionnels j'ai la maintenance d'un serveur de conversion de fichiers basé sur Libre Office, et quand on voit qu'il crée à chaque fois un gros environnement et qu'il lance la suite en ligne de commande, même en activant le mode sans interface graphique ça prend pas mal de mémoire. Alors des vrais SO avec des API claires et documentées, là je serais preneur. Et la fondation Apache est plutôt douée pour maintenir des librairies, regardez tout le projet java-commons par exemple.
Mais se concentrer sur le fait de rattraper le retard sur Libre Office, ça c'était vraiment la dernière chose à faire.







Répondre avec citation











Partager