Fork (développement logiciel)

Pour les articles homonymes, voir fork.

Un fork, ou embranchement ou fourche, 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.

Un fork peut être bénéfique pour un projet donné lorsque sa gouvernance actuelle conduit à une impasse, sa reprise par un nouveau groupe pouvant le relancer. Il peut aussi être néfaste en provoquant un éparpillement des ressources.

Un fork peut naître à la suite de divergence de point de vues ou d'objectifs parmi les développeurs, ou encore à la suite de conflits personnels. Les projets parents et dissidents peuvent avoir des rapports amicaux (fork amical) ou bien conflictuels (fork inamical). Quels que soient les rapports entre les deux projets, les licences de logiciels libres permettent l'emprunt de code d'un projet vers l'autre. Ainsi, les différents BSD s'empruntent régulièrement du code car ils partagent la même licence.

Une illustration de la régulation des projets libres par ce moyen est l'apparition d'au moins trois forks libres pour le projet SourceForge à l'issue de la « dérive de SourceForge » :

• Gforge
• Debian SF
• GNU Savannah
• Codendi
• et d'autres qui ne sont plus maintenus.

Spork

Une autre catégorie de fork existe et elle porte le nom de « spork ». Ce type de fork est initié à la suite de problèmes relationnel avec le mainteneur principal d'un paquet logiciel qui refuse de se conformer au rôle classique d'un mainteneur. Par exemple, il refuse d’intégrer des corrections tout à fait valides ou de nouvelles fonctionnalités sans en donner la raison. Le spork consiste à prendre le code source du projet amont et à lui appliquer les patchs légitimes rejetés par ce dernier.

Un spork permet de partager l'effort de maintenance en aval du projet. Au lieu que chaque distribution maintienne indépendamment un ensemble de patchs à appliquer au projet amont, elles peuvent ainsi partager l'effort en créant un projet intermédiaire qui rassemble les patches communs, il ne reste alors plus aux distributions qu'à gérer les patchs spécifiques à leur propre distribution.

Ce fut le cas notamment de projets tels que:

• eglibc qui est un spork de la glibc qui intègre des patches légitimes refusés par Ulrich Drepper. Debian utilise la eglibc depuis 2009.
• Go-oo était un logiciel dérivé d'OpenOffice.org, incluant des patches non intégrés par Sun Microsystems pour cause de lenteur d'intégration ou d'opposition à la politique commerciale de Sun. Depuis le rachat de Sun par Oracle Corporation, la situation s'est encore détériorée. Devant le silence d'Oracle sur l'avenir du projet, le spork s'est transformé en un véritable fork nommé LibreOffice. Si Go-oo était principalement utilisé par OpenSuse et Ubuntu, LibreOffice est maintenant utilisé par quasiment toutes les distributions.

Une 'cuillère-fourchette' japonaise

En langue anglaise, une 'spork' est une 'cuillère-fourchette', mot-valise créé à partir des deux mots spoon (cuillère) et fork (fourchette). Du fait de la dualité de fonction de l'objet, l'analogie a été conservée avec les embranchements informatiques qui gardent à la fois les fonctions existantes, et en rajoutent de nouvelles.

Exemples de forks

• GNU Emacs, suite à des différences de point de vue entre le projet GNU (qui était à l'origine de cette version d'Emacs) et des développeurs externes (principalement de l'entreprise Lucid qui développait un produit utilisant GNU Emacs), donne GNU Emacs et Lucid Emacs (qui est ensuite renommé en XEmacs).
• En 1994, Theo de Raadt, cofondateur de NetBSD est exclu par les développeurs de ce dernier. Il crée alors OpenBSD à partir du code source de NetBSD, et décide de rendre son développement le plus ouvert possible (d'où le "Open") tout en portant l'accent sur la sécurité.
• En 1997, GNU Compiler Collection (GCC) stagne et le fork EGCS apparaît pour progresser plus vite, notamment dans le support du C++ standard. Finalement, la branche EGCS supplante la branche stagnante de GCC en 1999 et est publiée sous la version 2.95.
• En 2003, un fork du logiciel libre de dessin vectoriel Sodipodi, nommé Inkscape est lancé. Aujourd'hui, Sodipodi n'a pas sorti de nouvelles versions depuis février 2004 alors qu'Inkscape connaît un développement très actif. Sodipodi était déjà à l'origine un fork du logiciel libre Gill.
• En 2003, suite à l'abandon apparent du logiciel de blog « b2 » par son créateur, Matthew Mullenweg et Mike Little décident de reprendre le projet sous le nom de WordPress. WordPress est aujourd'hui l'un des systèmes de gestion de contenu les plus utilisés sur le Web.
• En 2004, suite à un désaccord de licence, un bon nombre de développeurs de XFree86 décident de créer X.Org à partir de XFree86 4.4 RC2. Très vite, X.Org remplace XFree86 dans la plupart des distributions Linux.
• En 2005, suite à la volonté de l'éditeur Miro de créer une fondation autour de Mambo, les développeurs décident de lancer Joomla!.
• Le 18 septembre 2010, création de Mageia suite à la liquidation judiciaire de Edge-IT qui participait à l'édition de la distribution Mandriva.
• Le 28 septembre 2010, création de The Document Foundation pour le développement de la suite LibreOffice, fork de la suite bureautique OpenOffice.org, par une communauté de développeurs et de contributeurs de cette dernière, insatisfaits du rachat de Sun Microsystems (éditeur d'OpenOffice.org) par Oracle Corporation.
• SkySQL et MariaDB fork de MySQL de Oracle également
• Blink, moteur de rendu HTML de Google, fork de WebKit, dont le développement a été annoncé le 4 avril 2013

Exemples de « fusions »

À l'inverse des forks, certains projets de logiciels libres décident de fusionner leur base de code car ils partagent des objectifs similaires ou parviennent à réconcilier leurs points de vue.

Exemples de fusion de logiciels libres:

• Après avoir forké, Compiz et Beryl ont fusionné en 2007 en Compiz Fusion.
• AspectWerkz et AspectJ avaient des approches différentes pour faire de la programmation orientée aspect. Ils ont fusionné dans AspectJ 5 et offrent toujours aux utilisateurs de continuer à utiliser l'approche qui leur convient.
• Ruby on Rails et Merb ont fusionné en Ruby on Rails 3.
• En 2010, Pylons et repoze.bfg fusionnent pour donner Pyramid.