Les fourches / forks

Ce document, présenté sous forme de questions réponses, explique ce que sont les fourches, leurs causes, leurs risques et en quoi elles peuvent être à la fois déstabilisatrices ou bénéfiques. Les responsables de projets logiciels libres pourront s'en inspirer pour prévenir et/ou gérer les conflits et les problèmes de gouvernance. Les utilisateurs de logiciels libres trouveront, eux, des explications sur un phénomène auquel ils ont sûrement déjà été exposés et, qui les a peut-être obligés à prendre en considération un nouveau logiciel pour un besoin précis. Et si ces explications arrivent au moment d'un choix, elles les aideront à choisir alors un logiciel libre plutôt qu'un autre.

Table des matières des questions / réponses

1. Définition / contexte / rôle / rapport au projet original et à la communauté
2. Points de vue sur des exemples de fourche
3. Avenir des fourches
4. Plateformes en ligne de gestion de sources
5. Financement
6. Conseils aux utilisateurs

Questions / Réponses

1. Définition / contexte / rôle / rapport au projet original et à la communauté

Q. Qu’est ce qu’une fourche (ou fork) ?

R. En informatique une fourche (d'après le Jargon français), ou encore un embranchement (selon Wikipédia), est un programme développé à partir des sources d'un autre. Le mot anglais original pour ce concept est le mot fork. Une fourche a souvent pour cause une divergence profonde dans la vie d'un projet informatique qui vise à créer un logiciel. Une telle divergence dans la vie d'un projet est un élément fort, une crise, générant généralement de fortes perturbations aussi bien pour les personnes qui gèrent le projet que pour les utilisateurs du logiciel géré par le projet. On pourrait comparer la création d'une fourche au niveau informatique à un divorce pour un couple d'humains.

Q. Quels sont les différents types de fourches ?

R. Il existe différents types de fourche, qui dépendent des raisons de la rupture. Ainsi ces différents types répondent tous à des besoins différents. On peut citer par exemple :

• la continuation d'un logiciel abandonné par ses auteurs originaux et qui permet de continuer à le faire vivre tout en s'affranchissant des soucis de marque du projet originel (ex : Kompozer qui est une fourche de NVU)
• une évolution d'un programme dans une direction différente (Firefox est originellement une fourche de la partie navigateur de la Mozilla Suite avant d'en devenir un produit)
• une libération d'un programme sous licence propriétaire (le rachat des sources de Blender pour les mettre sous licence libre est un exemple)
• une propriétarisation d'un logiciel libre (Cedega est une fourche propriétaire de Wine)
• une divergence dans la gouvernance du projet (X.org est une fourche de XFree86 suite à un désaccord sur la licence du logiciel).

Q. Quels sont les effets sur le projet original ?

R. Les effets sur le projet original peuvent n'avoir que très peu d'incidence (par exemple FreeBSD est toujours là malgré les nombreuses fourches de ce système d'exploitation).

Mais il peut aussi le tuer (Sodipodi, l'original, est totalement abandonné alors que Inkscape est très actif). Quelques fois, il permet aux deux projets d’être en concurrence sur la qualité (exemple Frugalware Linux qui est une fourche à suivre de Slackware Linux).

Il peut n'avoir aucune incidence car la fourche se meurt (de nombreux développeurs se sont essayés, par défi technique ou personnel, à maintenir une fourche d'une distribution majeure de GNU-Linux et ont arrêté au bout d'un moment).

Cependant une fourche affaiblit forcément le projet original qui perd des contributeurs, qu'ils soient les développeurs historiques très expérimentés, ou bien des nouveaux venus. Mais il y a également des pertes de futurs contributeurs qui auraient participé au projet original si la fourche ne les avait pas captés.

Plus précisément ce qui va se passer dépend :

• de la pertinence de la raison de la fourche (s'agit-il d'un caprice ou bien est-ce un pan technologique ou commercial qui est bloqué ? )
• du sérieux, de la légitimité et de l'empathie de celui ou ceux qui fourchent (personnalités qui rassemblent, décideurs forts capables de sortir le projet de l'indécision ou de la paralysie)
• des réactions de ceux qui maintiennent le projet original, notamment en ce qu'elles sont en accord ou non avec l'esprit du logiciel libre (mépriser le danger, se lancer dans une bataille de communication, saluer la concurrence, innover, ouvrir plus avant la gourvernance du projet)
• de l'endurance de celui ou de ceux qui fourchent face à la volonté des auteurs originaux
• de l'adhésion des utilisateurs aux nouveaux choix qui s'offrent à eux

Il est totalement impossible de prévoir à l'avance l'impact qu'aura la fourche sur le projet initial ou sur la communauté. Et ce d'autant plus que des effets boule de neige peuvent se produire et des acteurs en entrainer beaucoup d'autres. On assiste aussi souvent, à ces occasions, à des acteurs qui dévoilent des stratégies jusqu'alors restées secrètes parce que ces changements ont redistribué les cartes.

Q. Le logiciel libre est-il toujours aussi intéressant quand on intègre cette problèmatique des risques liés aux fourches ?

R. Le fourchage n'est pas forcément une spécificité du logiciel libre. En effet, il existe de nombreuses fourches de logiciels propriétaires souvent méconnues voire totalement inconnues (secret industriel des différentes parties) suite au rachat de l'entreprise éditrice par une autre ou carrément un achat du code source d'un logiciel pour le développer dans une autre direction. Évidemment si le projet est distribué suivant une licence libre cela simplifie grandement les problèmes relatifs aux droits d'auteurs pour déterminer si le fourchage est licite ou non sur l'ensemble ou un sous-ensemble du projet original. Ensuite du fait de l'ouverture des codes sources l'étendue du code fourché est concrètement visible par tous et la comparaison avec le projet original réalisable. Donc la réponse est plutôt oui le logiciel libre reste toujours aussi intéressant même lorsqu'on intègre cette problématique des risques liés aux fourches. Car, même si il y a beaucoup plus de facilité à fourcher un projet libre qu'un projet propriétaire, initier une fourche prend beaucoup de temps et d'énergie : il faut généralement trouver un nouveau nom, acheter un/des nouveaux noms de domaine (nouveau-projet.org, nouveau-projet.net, etc.) mettre en place un nouveau site web si possible collaboratif, des listes de diffusion pour les contributeurs, injecter le code source dans un nouveau dépôt de sources, et sur le plan humain, créer une nouvelle structure de gouvernance pour le nouveau projet. Au delà de la fourche technique, du logiciel lui-même, il faut également gérer la fourche de la communauté. Les contributeurs non développeurs impliqués au niveau de la traduction ou de l'assurance qualité par des tests automatiques ou manuels doivent pouvoir poursuivre leur investissement participant à la renommée et la qualité du logiciel. Il faut donc reconstruire outils et méthodes à leur destination.

Q. Je suis entrepreneur, j'ai peur des risques de fourches. Comment puis-je m'en prémunir ?

R. De nombreux entrepreneurs craignent la fourche et hésitent à se lancer dans l'aventure du logiciel libre. Parfois, c'est à raison (tout dépend du marché visé, de la concurrence, du model d'affaires, etc.), mais le plus souvent c'est à tort.

Il faut en effet bien avoir en tête que dans le monde du libre, la fourche est l'exception, pas la règle.

Aussi à ceux qui ont ces craintes nous disons : Lancez vous ! Si vous craignez vraiment cette épée de Damoclès, gérez ce risque comme une obligation de qualité, d'innovation et d'écoute des besoins des utilisateurs plus que comme une menace. Si vous développez régulièrement et loyalement le logiciel, personne n'aura intérêt à fourcher votre projet. Et quand ce n'est pas le cas, quand les utilisateurs et contributeurs se sentent lésés la sanction tombe : on peut citer le logiciel Jenkins qui a fourché, début 2011, à partir du projet Hudson suite à des conflits avec Oracle qui avait récupéré ce projet au départ initié par Sun lors du rachat du deuxième par le premier.

2. Points de vue sur des exemples de fourche

Q. Plusieurs fourches majeures en terme stratégique et commercial se sont succédées et ont fait parler d'elles : MySQL (fourchée notamment en MariaDB et Drizzle mais aussi en plusieurs forks d'entreprises assurant du support sur MySQL), OpenOffice.org (fourché en LibreOffice), Mandriva (fourchée en Mageia) pour ne citer que les principales. Que penser de ces exemples sur des logiciels aussi importants ?

R. Les conditions et motivations menant à une fourche forment un contexte à chaque fois unique, et chaque fourche a son histoire. Mais notre point de vue est que, globalement, dans une majorité de cas les fourches sont nécessaires. On ne se lance en général pas dans ce genre d'effort si il n'y a pas un malaise persistant.

Il y a de nombreuses fourches de MySQL. On verra si elles se maintiennent et arrivent à prendre vraiment des parts de marché sur le long terme. Il est encore trop tôt pour faire de réelles prévisions. Cependant, il faut voir que MySQL est critique pour bon nombre d'entreprises utilisatrices (notamment celles qui ont choisi la version commerciale et le support correspondant) et ces entreprises craignent de perdre le support de la part d'Oracle et se voir un jour imposer, en lieu et place, le SGBD Oracle. Il y a donc un marché à prendre sur le support de MySQL et c'est ce qu'ont fait les fondateurs de SkySQL. Nous voyons positivement qu'il y ait un peu de concurrence, y compris au niveau du support « bas niveau » d'un même logiciel, cela stimule tout l'écosystème. Et, pour être complet, outre la possibilité de choisir migrer de MySQL à une fourche de MySQL, évoquons une autre possibilité : migrer de MySQL vers PostgreSQL, un autre logiciel libre SGBD relationnel SQL largement aussi puissant et complet. Cependant cette migration est rarement triviale et demande un travail d'adaptation complètement dépendant de la manière dont les applications à migrer ont été conçues.

LibreOffice, la fourche d'OpenOffice.org, est probablement la fourche qui fait parler le plus d'elle et surement pour quelques temps encore. Cette suite bureautique est devenue tellement importante et tellement critique pour le monde du libre et les différents acteurs gravitant autour qu'il était vraiment plus raisonnable de la sortir de chez l'éditeur pour continuer le projet dans une optique de développement communautaire pur. Cela a l'avantage de rendre ce logiciel plus résistant aux stratégies industrielles des uns et des autres, tout en leur permettant de travailler ensemble sur un même projet (ce qui est plus problématique quand le projet est principalement hébergé par une entité commerciale). Il est plus aisé d'en assurer alors sa pérennité. Nous souhaitons donc une belle et longue vie à la Document Foundation et nous espèrons qu'elle saura réussir ce beau pari sur l'avenir et devenir aussi emblématique, indépendante financièrement que, par exemple, la Mozilla Foundation, la Linux Foundation ou la Apache Foundation.

Pour ce qui est de Mageia, fourche de Mandriva (qui est, pour mémoire, une fourche de Red Hat), la fourche est toujours en cours de réalisation, il est donc difficile de parler sur du concret. Cette fourche a principalement été réalisée par d'anciens employés de l'éditeur et par quelques contributeurs suite à l'arrivée d'un nouvel investisseur qui a imposé une restructuration des dettes assortie d'une simplification de l'organisation. Cela rend les relations avec l'entité commerciale relativement difficile. Du moins jusqu'à ce que l'émotion retombe, que l'état des lieux soit fait et que chacun définisse son périmètre d'évolution. Cette fourche peut être bénéfique pour Mandriva et aux futurs utilisateurs de Mageia, tout comme Fedora est bénéfique à Red Hat. Ce pourrait être un moyen pour Mandriva de s'appuyer plus efficacement sur sa base d'utilisateurs.

3. Avenir des fourches

Q. Concernant les fourches de MySQL et de OpenOffice.org, si on peut comprendre les raisons de leur création, elles visent clairement les projets originaux, quitte à leur nuire. Est-ce une situation inédite ?

R. Pour ce qui est d'être inédit, non ça ne l'est pas. Le logiciel libre a une histoire vieille comme l'informatique, car à l'origine de l'informatique l'échange du code était la normalité. Cela s'est juste formalisé comme tel, vers le début des années 80, quand certains ont choisi de ne plus partager leur code et de le protéger légalement (pour simplifier et vulgariser).

Q. A-t-on à faire à des volontés d'indépendance par rapport aux grands éditeurs ? Si cela peut se comprendre, les éditeurs ont tout de même financé et contribué aux développements de ces projets.

R. Si les éditeurs ont certes payé et développé ces projets, il ne faut pas oublier de valoriser l'implication des utilisateurs et des contributeurs non-affiliés. OpenOffice.org par exemple est disponible dans plus de 70 langues (et dans des langues "minoritaires" jugées comme non rentables par Microsoft Office), quel en a été le coût pour l'éditeur ? Quels sont les coûts relatifs aux dictionnaires de correction orthographique ? Quel est le coût du soutien et de l'aide aux utilisateurs ? Quelle est la valorisation des remontées de bogues et de propositions de correction (patch) qui arrivent gratuitement ?

Il faut bien comprendre qu'après un grand nombre de contributions un logiciel libre n'appartient plus uniquement à son éditeur originel, il appartient alors dans les faits à ses utilisateurs et à ses contributeurs. Certains l'apprennent tardivement ou le redécouvrent.

En même temps, une fourche est un gage de succès du logiciel, cela veut dire que la base existante est bien faite et qu'elle vaut l'implication nécessaire de quelques personnes pour continuer de la maintenir et de la faire évoluer.

Q. Dans le cas de LibreOffice, par exemple, comment les utilisateurs réagissent-ils lorsque le nom du logiciel change ? Déjà que le rachat de Sun avait quelque peu fragilisé OpenOffice.org.

R. Il n'y a pas trop de confusion pour les utilisateurs. Le simple utilisateur passe d'un logiciel à un autre similaire sans problème, notamment si ces logiciels sont libres et gratuits et que les données utilisateurs ne sont pas enfermées dans un format connu seulement du premier logiciel. C'est bien le cas ici puisque le format utilisé reste OpenDocument, normalisé ISO 26300:2006.

Q. Peut-on avoir une fourche inversée, c'est à dire une fusion ?

R. C'est arrivé à Compiz, un logiciel qui permet d'obtenir un bureau avec des effets 3D. Suite à un désaccord sur des choix techniques, une fourche nommée Beryl a été créée. En 2007, après un an d'existence, les deux branches ont fusionné. La fourche a donc permis d'explorer des solutions qui ne l'auraient pas été autrement et de continuer en utilisant les meilleures options possibles.

4. Plateformes en ligne de gestion de sources

Q. Que sont les plateformes en ligne de gestion de sources, des réseaux sociaux d'échange de code ?

R. Ce sont des plateformes permettant la mise en ligne de projets majoritairement libres / Open Source mais aussi propriétaires. Elles permettent à tous les utilisateurs (principalement des développeurs) d'effectuer très facilement une fourche des différents projets ainsi hébergés en ligne. En d'autres mots elles permettent la création d'un dépôt fils similaire au dépôt maître.

Trois exemples de plateformes en ligne de gestion de sources :

• Gitorious, qui est précurseur en la matière, a vu le jour en Janvier 2008. Gitorious est un projet libre publié sous licence GNU AGPL (Affero General Public License), cette plateforme utilise, comme son nom l'indique, le logiciel de gestion de versions décentralisée Git.

• GitHub est née peu après le lancement de Gitorious, puisqu'elle a été mise en place en Février 2008. Là aussi, GitHub utilise la technologie Git pour permettre aux utilisateurs de gérer les différentes versions d'un projet. Seule ombre au tableau, GitHub n'est pas un projet libre, c'est un projet propriétaire.

• BitBucket est quant à elle apparue à la fin de l'année 2008. Cette plateforme utilise, contrairement aux deux précédentes, le logiciel de gestion de versions décentralisée Mercurial. C'est aussi un projet propriétaire. BitBucket a été acquis le 29 septembre 2010 par l'entreprise Atlassian.

Gitorious https://gitorious.org/

Q. Quels sont les avantages de ce type de plateforme et qu'apportent-elles de nouveau ?

R. La principale nouveauté de ces plateformes est qu'elles fonctionnent comme un réseau social. De plus le fourchage d'un projet est aussi simple que le clic sur un lien. Outre le fait qu'il est possible de récupérer un clône, le principal intérêt est que les modifications effectuées par chaque développeur peuvent être mises en ligne et rendues visibles à tous sans avoir à monter et gérer soi même un site web pour cela.

Q. Ce fonctionnement ne remet-il pas en cause l'intégrité du projet ?

R. Heureusement, les modifications ne remettent pas en cause l'intégrité du projet puisque chaque fourche effectuée entraine la création d'une branche fille parallèlement à la branche mère (ou master). Seuls les développeurs affiliés décident de l'intégration ou non de certaines modifications dans le dépôt maître en fusionnant les branches. La branche fille créée contient le projet modifié et est rendue accessible à tous, aussi bien pour une utilisation personnelle que pour une contribution.

Q. Finalement, la création de fourche est-elle purement collaborative ?

R. La fourche (fork) de GitHub n'est, en fait, pas un fourchage du projet, mais une simple branche toujours raccordée à l'arbre principal qui est géré par l'équipe / la communauté du projet. La fourche de GitHub n'est donc en rien comparable aux fourches révolutionnaires comme l'est LibreOffice.

5. Financement

Q. Finalement, l'un des problèmes de ces grands projets n'est-il pas la stabilité financière et comment financer les développements ?

R. C’est l'éternelle question des modèles économiques et de la rémunération du code. Nous pensons qu'il y a moyen de faire de l'argent et de stabiliser le financement de bon nombre de logiciels libres. Cependant il faut pour cela qu'une certaine proportion des bénéficiaires joue le jeu pour pérenniser les projets. À chaque projet ses modèles économiques applicables ; d'ailleurs l'AFUL maintient une liste des différents modèles économiques liés au libre.

Néanmoins, la pérenniité d'un projet libre ne peut être assurée qu'avec l'aide des acteurs l'utilisant dans leurs activités commerciales. Typiquement pour OpenOffice.org, beaucoup d'intégrateurs ou sociétés de services facturent du support technique niveau 3 sans reverser au projet ni code ni argent. Ce qui est navrant. Espérons qu'avec LibreOffice et la Document Foundation ces intégrateurs reverseront leurs contributions voire commanderont des prestations de développement à la fondation si elles n'ont pas les compétences pour réaliser certaines tâches.
C'est un modèle gagnant-gagnant : le client a une suite qui fonctionne conformément à ses besoins, l'intégrateur gagne en image de marque et en expertise (sans compter les rapports privilégiés avec la fondation), la fondation reçoit des contributions en nature ou financière, tous les autres utilisateurs bénéficient du code produit et payé par un autre. Les utilisateurs peuvent également mettre la main à la poche pour quelques euros de temps en temps afin de soutenir ceux qui travaillent bénévolement.

6. Conseils aux utilisateurs

Q. Avant d'utiliser la fourche, qu'est-ce que l'utilisateur doit regarder ?

R. Ça dépend de la fourche et de l'utilisateur. Dans tous les cas, il faut faire très attention à son patrimoine numérique et il faut s'assurer que ses données originelles soient toujours lisibles par la fourche choisie et que les données produites par la fourche le soient également du projet inital. Bien évidement, ces logiciels doivent utiliser des standards ouverts (il est très rare que ce ne soit pas déjà le cas avec un logiciel libre). Le plus important, avant même l'ouverture du code et les libertés accordées par la licence, ce sont les libertés, la pérennité et l'interopérabilité des données de l'utilisateur. Si l’utilisateur est un simple utilisateur d'une distribution GNU-Linux, nous lui recommandons de faire confiance aux choix effectués par les développeurs de la distribution lors des mises à jour. Ces développeurs communiquent beaucoup entre eux et les autres distributions GNU-Linux et sont généralement très bien informés.

Si l'utilisateur est un simple utilisateur sur Windows ou Mac OS X, nous recommandons grandement de faire davantage confiance aux conseils des utilisateurs chevronnés.

Enfin si un utilisateur veut devenir contributeur en s'impliquant davantage dans un projet, il lui faut alors plutôt choisir le projet qui saura le mieux prendre en compte ses remontées de bogues et ses contributions de code.

Ce document a eu pour origine un entretien de Laurent Séguin dans la revue Programmez! n°136 de décembre 2010 que les membres de l'AFUL ont souhaité compléter et faire évoluer.