OpenOffice.org n’est pas mort, Vive LibreOffice !

Comme le souligne avec malice notre ami Gee, la suite bureautique libre LibreOffice 3.3 vient de voir le jour.

Sauf que, comme son numéro ne l’indique pas, c’est sa toute première version stable. Mais alors pourquoi n’a-t-on pas logiquement une version 1.0 ? Parce qu’il s’agit d’un fork de la célèbre suite OpenOffice.org qui, au moment de la séparation, en était restée à la version 3.2.

Petit rappel Wikipédia : « Un fork, ou embranchement, est un nouveau logiciel créé à partir du code source d’un logiciel existant. Cela suppose que les droits accordés par les auteurs le permettent : ils doivent autoriser l’utilisation, la modification et la redistribution du code source. C’est pour cette raison que les forks se produisent facilement dans le domaine des logiciels libres. Les forks sont perçus par certains comme une épée de Damoclès au-dessus des auteurs des projets les moins bons, et aussi comme une méthode pour empêcher l’appropriation d’un projet par un groupe. La « peur de l’embranchement » est un des mécanismes essentiels de régulation et de sélection des projets libres. »^[1]

Vous êtes un développeur d’un logiciel libre non satisfait de la manière dont évolue le projet ? Vous avez donc cette possibilité essentielle que constitue le fork. Mais il y parfois un gouffre entre la théorie et la pratique, car il n’est pas simple de reconstituer une communauté active autour du projet dérivé.

C’est pourtant justement ce que vient de réussir l’équipe de LibreOffice, structurée autour de la Document Foundation et qui a décidé de quitter le navire OpenOffice.org suite au rachat de Sun par Oracle. Ce dernier ayant refusé de rejoindre le projet et de céder la marque OpenOffice.org (qu’il continuera de développer par ailleurs), c’est donc désormais LibreOffice (ou LibO) qui sera l’un des fers de lance du logiciel libre grand public aux côtés de Firefox ou GNU/Linux.

LibreOffice 3.3 : les véritables enjeux

The Deeper Significance of LibreOffice 3.3

Glyn Moody – 28 janvier 2011 – ComputerWolrd.uk
(Traduction Framalang : Yonel et Don Rico)

Sur le blog RedMonk, James Governor a publié un billet amusant à propos des forks, suite à l’arrivée imminente d’une mise à jour majeure d’Android, la 3.0, dont le nom de code est « Honeycomb », et laquelle a été conçue en pensant aux tablettes :

Ainsi que le voudrait la sagesse populaire, les développeurs ne devraient pas s’attaquer à des environnements multiples. Ben voyons… le genre de sagesse qui nous a valu une décennie où il n’y en a eu que pour Java, et une vingtaine d’années pendant lesquelles dès qu’il y fallait choisir une architecture on collait du Oracle partout. Avouons que pour l’instant, Android est vraiment pas mal sur les téléphones. J’aime beaucoup mon HTC Desire. J’ai aussi la chance de pouvoir faire joujou avec un Dell Streak qu’on m’a prêté ; encore un bon petit appareil, qui fait bien son boulot pour m’accompagner devant la télé. Mais Android n’a pas été conçu pour un format plus grand, comme l’iPad 10 pouces d’Apple, du moins dans ses premières versions.

Et comme il le fait remarquer :

Tous les éditeurs de logiciels doivent gérer des codebases multiples, en particulier pour les progiciels. Si une entreprise doit gérer les deux codebases, est-ce vraiment un fork ?

Je dirais qu’il s’agit plus de fragmentation, et qu’on en voit partout – dans Android lui-même, dans Windows, admettons, et dans le monde de GNU/Linux à travers les centaines de distributions, chacune avec des versions et des configurations différentes. Rien de bien nouveau.

Les vrais forks ne courent pas les rues, précisément à cause des différences entre le fork et la fragmentation. Cette dernière peut être gênante ou pas, mais elle est rarement aussi douloureuse qu’un fork peut l’être. En général, les forks déchirent les communautés et forcent les programmeurs à choisir leur camp.

C’est ce qui rend l’apparition de LibreOffice si intéressante : c’est un vrai fork, avec des décisions réelles et douloureuses que doivent prendre les codeurs – où vont-ils ? Et à la différence de la fragmentation, qui souvent se produit naturellement et perdure pour un tas de raisons en grande partie banales, les forks exigent beaucoup de travail pour survivre. Résultat, de nombreux forks échouent, car il est souvent plus facile de rester ou de revenir au projet d’origine, plutôt que de se battre pour en installer et en faire grandir un nouveau.

Dans ce contexte, la publication récente de LibreOffice 3.3 est un jalon important, au moins pour ce qu’elle a déjà réussi :

La Document Foundation présente LibreOffice 3.3, la première version stable de la suite bureautique libre développée par la communauté. En moins de quatre mois, le nombre de développeurs codant LibreOffice est passé de moins de vingt à la fin septembre 2010, à largement plus d’une centaine aujourd’hui. Cela nous a permis de publier en avance par rapport au calendrier audacieux fixé par le projet.

À l’évidence, attirer les développeurs est une épreuve cruciale pour le potentiel de survie du fork, et même de son épanouissement. D’autres points importants :

La communauté des développeurs a pu bâtir ses propres méthodes en toute indépendance, et devenir opérationnelle en très peu de temps (eu égard à la taille du codebase et aux grandes ambitions du projet).

Grâce au grand nombre de nouveaux contributeurs qui ont été attirés par ce projet, le code source est vite soumis à un nettoyage d’ampleur, pour offrir une meilleure base aux développements de LibreOffice à venir.

C’est-à-dire que LibreOffice n’en est plus au stade de vague projet, ou à celui des étapes pénibles comme définir l’infrastructure qui permettra au projet d’avancer. La signification de cette réussite va au-delà du fait que la Fondation propose aux utilisateurs une alternative libre à OpenOffice (qui vient également de sortir sa dernière version). La possibilité de choix étant au coeur du logiciel libre, c’est donc certainement une bonne nouvelle, surtout à cause de la politique de copyright de LibreOffice, que j’ai déjà évoquée.

Mais je pense que LibreOffice a une importance supplémentaire parce qu’il représente une attaque délibérée contre la façon dont Oracle traite son catalogue open-source. Hélas, le mécontentement qui a poussé à cette scission va bien plus loin que le seul domaine des suites bureautiques.

L’attitude d’Oracle envers la communauté open-source semble empirer, c’est de plus en plus évident. Marc Fleury le résume bien dans ce billet révélateur. Fondateur de Jboss, et l’un des vrais innovateurs en termes de modèles économiques reposant sur l’open-source, il sait certainement de quoi il parle quand il s’agit de diriger des codeurs open-source dans un contexte professionnel, ce qui rend des commentaires comme celui-ci particulièrement significatifs – et inquiétants pour Oracle :

Il y a d’abord eu le fiasco OpenOffice/Libre Office, où OpenOffice a été forké dans la plus grande partie par sa propre communauté. Puis il y a eu le caprice d’Apache concernant Java/JCP, quand le groupe a bruyamment quitté le JCP (NdT : Java Community Process) après des prises de bec sur les licences open-source de la JVM (Harmony). Et en ce moment, il y a d’autres bisbilles, dont une au sujet de NetBeans. Mais celle qui me concerne le plus (ainsi que mon porte-monnaie), cela concerne un projet mené par un employé de Cloudbees.

Si je comprends bien la situation, le principal développeur était employé par Sun quand il a initié Hudson. Oracle revendique donc l’identité et la marque, ce qui en toute franchise est aberrant, puisque la licence est open-source et que les gars de Cloudbees peuvent poursuivre leur travail sans entrave. Reste donc une dernière étape : la création d’un fork du projet. Et voilà… une grande partie de la communauté open-source dit merde à Oracle.

Ce que LibreOffice montre (jusqu’ici, en tout cas) c’est que dans ces circonstances, il y a bien une vie après Oracle, que les gens se regrouperont dans un fork au lieu de l’éviter, et que le travail alors fourni amène des améliorations non négligeables. Il est vrai que cet argument ne s’appuie que sur un seul exemple, et il faudrait être un expert bien téméraire pour essayer d’en extrapoler quoi que ce soit. Mais cela reste une source d’inspiration importante et tentante pour les codeurs contrariés qui grognent sous le joug d’Oracle. Après tout, comme le met en évidence le nom de LibreOffice, il ne s’agit pas que de code. Il s’agit aussi de liberté.