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.

mysql_vs_mariadb

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.

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.

openoffice-vs-libreoffice

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.

freebsd_versus_dragonflybsd

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-logo-purpy

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.

21 thoughts on “Dans le Libre : la bifurcation (fork)

  1. Je pense que tu as oublié un cas de bifurcation, bien que tu l’aies illustré via une image : la bifurcation « idéologique sous couvert technique ».

    Ou en terme plus simple : « bisque, bisque, rage ». Devuan en est l’exemple parfait. D’ailleurs, pour moi, ce fork se résume au final à un « tout ça pour ça ». Il suffit de mettre côte à côte Debian et Devuan. Modulo l’écran de connexion graphique et le remplacement de NetworkManager par Wicd, l’utilisateur « moyen » ne verra pas la différence. Du moins au premier coup d’oeil.

    Lorsque j’ai osé dire que des personnes abusaient du principe, je me suis fait traité de tous les noms, osant remettre en cause *ce qui était faux !* le principe même du fork.

    Le fork ou bifurcation contient en lui même sa propre dérive. Pour LibreOffice, c’est pour que la suite bureautique évolue et survive au pourrissement sur pied suite au rachat d’Oracle.

    Tu as cité des exemples de forks pour passer à une nouvelle génération de python. Et c’est aussi un forme de survie.

    Le fork est essentiel. Mais il ne faut pas en abuser. Pour reprendre le slogan de la sécurité sociale : « Le fork, c’est bien ! En abuser ça craint ! »

    Pour finir, il y a parfois des forks qui sont réintégré au code d’origine. Un exemple : Beryl qui avait forké du code de Compiz à l’origine pour donner Compiz Fusion.

    • J’ai inclus ta première remarque dans un cas que j’aborde : le problème du leadership. J’essaie dans cet article de bien mettre en avant que bien souvent la bifurcation dans la vie d’un logiciel libre n’est pas un événement technique mais plutôt social, issu des dissensions des gens au sein de ce projet. Et je pense aller donc dans ton sens en citant Devuan qui fut clairement un feu follet 🙂 J’essaie de décrire les risques de cette pratique, divisant les ressources d’un projet et la mauvaise presse qui s’en suit.

      Maintenant, c’est une pratique intrinsèque (car les conditions en sont décrites dans les licences) au Logiciel Libre et saine lorsqu’elle est intelligemment appliquée. Inutile de tenter vainement de contribuer à un projet dont le leadership a désormais verrouillé le modèle et ne reçoit plus/ne veut plus recevoir de contributions. Il faut bien sûr tenter le maximum de choses avant de l’employer, mais après, la base de code est là pour tenter de repartir.

      • Autant / au temps pour moi pour ta première remarque.

        Sinon, pourquoi parler de Devuan au passé ? Le projet semble toujours bien vivant, bien que dans l’impossibilité *apparente* de sortir une première version stable du projet.

        « Maintenant, c’est une pratique intrinsèque (car les conditions en sont décrites dans les licences) au Logiciel Libre et saine lorsqu’elle est intelligemment appliquée.  »

        Sur ce plan, je ne puis qu’applaudir des deux mains. Le hic, étant que l’application intelligente, elle manque parfois 🙁

         » Inutile de tenter vainement de contribuer à un projet dont le leadership a désormais verrouillé le modèle et ne reçoit plus/ne veut plus recevoir de contributions. »

        Pourquoi un projet terminant par Cloud me vient à l’esprit ? 🙂

        « Il faut bien sûr tenter le maximum de choses avant de l’employer, mais après, la base de code est là pour tenter de repartir. »

        Heureusement que LibreOffice et Mageia en sont la preuve ici 🙂

        Même si Mageia a un mal de chien à sortir sa version 6.0 🙁

        • Pour Devuan en effet je ne devrais pas en parler au passé mais je l’ai fait ici pour deux raisons : la première étant que je constate un relâchement très fort de la haine des sysadmin vis-à-vis de systemd. Nombreux sont ceux qui ont commencé à apprécier certaines de ses fonctionnalités en production à l’usage. La seconde est que ça a « buzzé » très très fort autour de Devuan et c’est aujourd’hui beaucoup beaucoup plus calme de ce côté.

          • « la première étant que je constate un relâchement très fort de la haine des sysadmin vis-à-vis de systemd.  »

            Ce n’est pas l’impression que j’en ai eu. À moins que je fréquente virtuellement les « mauvais » cercles ? 😀

            « La seconde est que ça a « buzzé » très très fort autour de Devuan et c’est aujourd’hui beaucoup beaucoup plus calme de ce côté. »

            Justement. On n’est pas à l’abri d’une résurgence d’intérêt avec le freeze de Stretch qui sera complet en février 2017.

  2. Encore un super article, merci !
    Les illustrations avec des exemples de Forks connus sont sympas, mais je trouve juste un peu dommage que tu ne mettes pas une ligne en dessous pour contextualiser le fork en question.

    Pourquoi MariaDB ? Et libreOffice ? Ah tiens, qui est Matt Dillon 🙂
    Évidemment, chacun peut faire ses recherches aussi…

    Un fork qui m’a pas mal marqué cette année, c’est OwnCloud/NexCloud, carrement hostile pour le coup, menée par le fondateur historique et qui a bien divisé la communauté.

    • Buzut : j’ai pensé à développer un peu les différentes bifurcations, mais ça risquait de faire des légendes d’image assez longues.

      Je voulais surtout illustrer le fait que les bifurcations sont monnaie courante dans le Logiciel Libre.

      On pourrait carrément faire un article par bifurcation comme celle de Owncloud/Nextcloud ou celle de MySQL/MariaDB par exemple 🙂

      • Bien vrai que si on veut entrer dans le détail c’est tout de suite long! A défaut de faire un article par fork, on peut peut être mettre un lien vers ledit fork pour chacun.

  3. Salut 🙂

    Je trouve cette série d’articles très pertinente, écrite d’une façon qui dé-passione les débats qui peuvent entourer ces thèmes.

    A ce sujet, j’ai l’impression que le problème de la communication entre les contributeurs est un point qui doit entraîner pas mal de fork, et qu’une façon apaisée de se dire certaines choses éviterais beaucoup des forks non-intelligent :-/

  4. Toujours agréable à lire Carl (d’autant que je comprends parce que la série cryptomonnaie perso…ouch… 😉 )

    Juste une petite remarque de simple utilisateur de logiciels (en général) libre dans le cas des bifurcations (ouais un terme en français \o/ ). Certains simples utilisateurs tel moi sont en revanche de (plutôt) gros promoteurs de telle ou telle logiciel. Lorsqu’une bifurcation, il y a une très forte inertie des gens à qui nous avons conseillé telle solution (disons OOo au hasard) et pour beaucoup, ils continuent sur le « canal historique » sans rien nous demander…..

    • Phipe : oui bien sûr, j’en parle brièvement quand je dis dans la partie des inconvénients de la bifurcation : « Mauvaise presse et incompréhension des utilisateurs (attaque d’autres communautés, pourquoi le changement de nom, quel est le « bon » projet ?) », c’est bien sûr nuisible dans un premier temps, qui peut être long comme tu le dis, avec une inertie importante pour les gros projets.

      Par contre sur le plus long terme, je pense que c’est une bonne chose. En effet le projet repart, souvent sur des bases plus saines avec une équipe vaccinée des problèmes rencontrés auparavant.

      Et je pense bien sûr très fort aux problèmes rencontrés à cause de sociétés commerciales comme Oracle ou MySQL) et des fondations apparaissent et vont protéger plus efficacement le projet par la suite.

  5. La bifurcation est une des grandes forces du logiciel libre… et en même temps son talon d’Achille. Il y a quelques années, j’ai commencé à expérimenter avec OwnCloud. Puis est survenu le fork, dans les conditions que l’on sait. J’ai expérimenté avec NextCloud, puis je suis revenu à OwnCloud, parce que j’avais l’impression que le développement se faisait de manière un peu moins frénétique, et avec un peu plus de considération pour la pérennité. Au final, ce fork n’a servi strictement à rien, sauf à diviser l’équipe… et à faire perdre du temps aux utilisateurs. Au passage, les gars de NextCloud se sont salement tiré dans le pied, parce que leur excellente documentation a été rédigée par Carla Schroder (auteur de deux bouquins excellents chez O’Reilly, et une de mes plumes préférées), et elle a été virée comme une malpropre. Je me dis qu’une équipe capable de virer Carla Schroder part déjà du mauvais pied.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *