Un fork, c’est, littéralement, une fourche. C’est exactement ce qui se dessine lorsqu’un projet se sépare en différentes branches, comme dans cette incroyable représentation des différentes distributions Linux.

Wikipédia, entrée Fork, nous dit:

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.

Si vous avez lu mes précédents billets sur le choix d’une licence et changelog et todo, vous comprenez déjà où je veux en venir. À condition de créer des conditions valables – offrir des droits (la licence) et permettre de comprendre ce que l’on a fait (le changelog) et ce qu’il reste à faire (le todo) –, il devient possible de faire des forks de projets autres que des programmes informatiques.

Reste donc à savoir pourquoi et comment on forke. Il y a en gros deux types de séparations: celle qui est amicale et celle qui ne l’est franchement pas. Quelques exemples:

• le fork amical: créer une version spécifique d’un produit, par exemple pour un public particulier, avec des spécificité qui ne méritent pas d’entrer dans le projet général.
•  et le fork technique, en général amical: le projet évolue et une ancienne version doit être abandonnée. Une équipe décide de reprendre cette ancienne version et de la maintenir à jour. Ou un équipe décide de faire avancer une branche du projet très rapidement, comme laboratoire pratique.
• vs le fork inamical: pour des raisons d’humeur, de désaccord technique majeur, de pouvoir, etc., des membres décident de créer un nouveau projet concurrent. C’est un schisme!

Il ne faut pas 5 minutes pour imaginer 10 projets (dans le monde ecclésial dont je parle souvent ici) qui mériteraient d’être maintenus selon une branche mère et des déclinaisons géographiques, pédagogiques, etc. Je vous laisse y réfléchir.

Pour rendre ce genre de choix possible, il faut un peu plus qu’une licence qui le permette et deux fichiers de documentation. Il faut, au minimum, pouvoir reprendre le matériau de base (code, textes, illustrations, etc.). Ce qui implique d’utiliser des formats acceptables, certainement ouverts, et si possible un système de gestion de version. Par un hasard heureux, c’est justement le sujet d’un prochain billet…