Dans le Libre : la bifurcation (fork)

Dans cette série d’articles consacrés aux usages du Libre et après avoir abordé les principales étapes de la démarche du Libriste pour résoudre un problème (gratter ses propres démangeaisons) par la création puis l’utilisation d’un programme (manger ce que l’on prépare) puis enfin l’automatisation de sa conception et de son déploiement (tout automatiser), nous nous intéresserons à l’une des pratiques les controversées mais aussi des plus efficaces du Logiciel Libre :  la bifurcation (fork en anglais).

Qu’est-ce que la bifurcation et pourquoi s’y intéresser ?

Le bifurcation dans le Logiciel Libre consiste à prendre les sources d’un programme sous licence libre pour créer un nouveau projet indépendant. Si la manœuvre technique en elle-même est le plus souvent assez simple, les motivations et les modalités de réalisation de ladite bifurcation sont nombreuses et les conséquences qu’elle entraîne pour le projet peuvent être importantes. Cette pratique est néanmoins courante et il est important de bien comprendre son rôle dans nos communautés techniques afin de ne pas en avoir peur, de la diaboliser ou pire de nier son rôle ou son efficacité quant elle est bien utilisée.

MariaDB, bifurcation de MySQL maintenant bien établie dans le paysage du Logiciel Libre

Les motivations derrière une bifurcation

Les motivations créant le besoin d’une bifurcation sont nombreuses. Pour n’en citer que quelques-unes :

• L’unique mainteneur d’un projet est injoignable
• Un projet accumule des bugs gênants et son mainteneur n’est pas suffisamment réactif ou n’est pas ouvert aux apports d’autres contributeurs
• Des différences de vision quant aux directions d’un projet s’accumulent
• Les points de vue des mainteneurs d’un projet divergent quant à l’ajout d’une fonctionnalité majeure

Et c’est là qu’on commence à sentir l’aspect social qu’entraîne une bifurcation. Car au-delà de la base de code, c’est aussi une communauté existante que la bifurcation va chambouler. Le chambardement est bien sûr très réduit lorsqu’il s’agit d’un projet constitué d’un seul mainteneur, souvent le développeur principal du projet. Mais sur des projets plus larges, une bifurcation peut entraîner le départ de mainteneurs du projet dont vous bifurquez… et donc un appauvrissement des ressources de ce projet. Il s’agit donc d’être sûr que les raisons sont réunies pour réaliser une bifurcation et que les points de vue sont – au moins pour l’instant – irréconciliables.

Un exemple simple vaut souvent mieux qu’un long discours. Je vais donc prendre l’exemple du projet rss2twitter, un outil sous licence MIT codé en Python 2 permettant de transformer les entrées d’un flux RSS en message à destination du réseau social Twitter. Les sources du projet sont présentes sur Github mais le dépôt n’évoluait plus depuis plusieurs années et le mainteneur ne répondait pas aux sollicitations. Le programme fonctionne néanmoins et tenait en quelques centaine de lignes. Souhaitant l’utiliser dans le cadre du Journal du hacker, j’avais donc toutes les raisons nécessaires de ne pas recoder un nouveau projet et de pratiquer une bifurcation pour lancer le nouveau projet Feed2tweet à partir de la base de code de rss2twitter.

Les modalités de la bifurcation

Avant tout, il s’agit de savoir si la licence du logiciel dont vous souhaitez bifurquer autorise cette pratique. Bonne nouvelle, la bifurcation est une des libertés fondamentales du Logiciel Libre, et se retrouve donc dans toutes les licences libres. Les modalités de la bifurcation sont bien souvent définies dans la licence elle-même. Dans les faits, si vous avez communiqué vos motivations aux responsables du projet ou même les avaient rendues publiques, le premier pas est engagé. Une communication auprès de ces mêmes personnes les avertissant de la réalité de la bifurcation permettra que les choses soient claires. À partir de ce moment-là, on distingue en général deux types de bifurcation : amicale et non-amicale.

NextCloud, bifurcation de OwnCloud, ayant entraînée la fermeture de OwnCloud Inc.

La bifurcation amicale tend à exploiter une voie qui ne sera pas exploitée dans le futur par le projet amont. Il peut s’agir d’une spécialisation du projet dans un domaine particulier ou de l’introduction d’une modification majeure. On peut prendre l’exemple d’une distribution GNU/Linux et d’une dérivée par exemple spécialisé dans la sécurité et donc beaucoup plus restrictive. Un exemple concret réside dans le moteur du Journal du hacker qui est une bifurcation amicale du moteur du site américain lobste.rs, dont j’ai bifurqué amicalement pour ajouter la gestion d’autres langues dans le moteur car le mainteneur du projet amont n’avait pas le temps de le faire. Il a donc été procédé à une bifurcation amicale afin d’implémenter ces modifications avec comme but de les intégrer plus tard au moteur du projet amont.

La bifurcation non-amicale annonce une rupture dans la continuité du projet. Dorénavant le projet d’origine et sa bifurcation vont évoluer en parallèle, à priori sans plus avoir de liens. La réalité est bien sûr plus complexe, surtout quand des membres du projet d’origine travaillent en parallèle sur les deux projets. Mais en tout cas, la rupture est consommée et rendue public. Les deux projets peuvent évoluer fortement l’un par rapport à l’autre, ou continuer à échanger régulièrement mais en gardant chacun leurs spécificités.

LibreOffice, bifurcation de OpenOffice suite au rachat de Sun par Oracle

Pour continuer sur mon exemple de Feed2tweet, j’ai largement communiqué autour de la bifurcation et de ses différentes étapes afin d’attirer d’éventuels contributeurs, ce qui a eu pour effet qu’on parle du nouveau projet et en effet d’obtenir quelques contributions et améliorations de la base de code, améliorations toujours bonnes à prendre par rapport à la base de code assez ancienne du projet amont.

Les avantages d’une bifurcation

Bifurquer un projet offre de nombreux avantages par rapport à tenter d’interagir en tant que contributeur au projet d’origine. Parmi les principaux :

• Totale liberté dans la façon de coder et ré-écriture majeure du code possible
• Nouveau leadership au sein du projet
• Possibilité d’introduire rapidement de nouvelles fonctionnalités majeures
• Choix complet de la nouvelle plateforme technique (dépôt de sources, outils de tests, intégration continue, etc)
• Possibilité de critiquer publiquement le projet amont, de montrer les erreurs commises et qu’une alternative est désormais possible
• Changement de la licence si le projet amont utilisait une licence libre très permissive (exemple MIT vers GPL possible)

Donc des arguments à la fois technique et d’organisation. Bien sûr dans le cas d’une bifurcation amicale, certains de ses avantages sont restreints, par à la fois le respect du travail toujours effectué en amont et la volonté d’y introduire certaines fonctionnalités en provenance du projet issu de votre bifurcation.

DragonflyBSD, une bifurcation de FreeBSD 4.8 menée par Matt Dillon

Pour continuer sur mon exemple de mon projet Feed2tweet, la bifurcation m’a permis à partir d’une base de code de corriger rapidement de nombreux bugs, de rendre modulaire le code, de passer en Python 3 et de changer de licence pour aller vers une licence libre plus restrictive protégeant à mon sens davantage mon travail et celui des futurs contributeurs du projet, en passant de la MIT vers la licence GPLv3, en s’assurant ainsi de ne jamais retrouver légalement mon code dans un logiciel propriétaire, contrairement à ce qui peut arriver lorsqu’on utilise la licence MIT ou BSD.

Les inconvénients d’une bifurcation

Si une bifurcation offre de nombreux avantages et une grande liberté, cette dernière présente néanmoins des inconvénients, qui bien souvent touchent à la fois le projet né de la bifurcation, mais également le projet bifurqué. Parmi ces inconvénients :

• Division des effectifs contribuant à un projet et donc dispersion potentielle des efforts
• Guerre de communication entre les deux projets en cas de bifurcation inamicale pour attirer contributeurs et utilisateurs
• Mauvaise presse et incompréhension des utilisateurs (attaque d’autres communautés, pourquoi le changement de nom, quel est le « bon » projet ?)

Dans l’esprit de membres des communautés du Libre, une bifurcation inamicale est toujours perçue comme à priori comme négative pour les raisons exposées ci-dessus.

Devuan, bifurcation sans grand succès de Debian sans Systemd

La bifurcation comme garde-fou

Nous avons pu voir que les arguments en faveur d’une bifurcation bien effectuée sont nombreux et attirants pour les développeurs d’un projet. Sans faire table rase du passé, la bifurcation va offrir de nombreuses libertés, qu’elles soient organisationnelles ou techniques, permettant de relancer un projet ou d’en créer simplement un nouveau. Évidement elle a aussi de lourds inconvénients, en particulier en terme de visibilité du projet par les actuels et potentiels contributeurs et utilisateurs.

Pourtant et comme vu plus haut, la bifurcation est souvent la seule façon de continuer à faire vivre un projet libre abandonné ou verrouillé par les actuels mainteneurs. Avec de nombreuses entreprises produisant dorénavant des logiciels libres, la bifurcation est le garde-fou assurant la possibilité pour les communautés du Libre de se réapproprier une base de code existante en cas de fermeture de fait du code par non-acceptation des contributions extérieures, base de code à laquelle elle a bien souvent largement participé.

S’il est bien sûr dommage que les mainteneurs et les contributeurs proposant de nouvelles fonctionnalités n’arrivent pas à faire avancer ensemble le projet d’origine dans la bonne direction, la bifurcation représente une issue de secours garantissant un possible renouveau non pas du projet d’origine mais de sa base de code, sous une forme altérée qui prendra peu à peu en tant que nouveau projet une forme propre. Au final, l’utilisateur bénéficiera d’une alternative mise à jour, complétée, certes différente du projet initial qu’il avait connu, mais relancée pour de bon et sorti d’une impasse organisationnelle et technique.