L'open source et le fork : quand devrait-on avoir recours au fork ?

Discussion dans 'Support informatique' créé par RedEye, 11 Mai 2014.

  1. RedEye

    RedEye - أبو عبدالرحمن - Membre du personnel

    J'aime reçus:
    4153
    Points:
    113
    Quelles sont les conséquences sur un projet ?

    Le fork, est-il le moyen d’expression favori des communautés open source ?

    Suite à une faille dans la solution de chiffrement open source OpenSSL, le fondateur du projet OpenBSD a procédé au fork de celle-ci pour créer LibreSSL, au lieu de contribuer à l’amélioration de la bibliothèque qui est largement supportée par l’industrie. Pour lui, le code d’OpenSSL ne serait pas assez propre.

    La naissance de ce nouveau fork, dont la justification ne nous semble pas assez convaincante, outre le fait que la diversité est non sans nous déplaire, nous amène à cette réflexion sur l’open source et les avantages/conséquences du fork.

    Pour rappel, le fork est la création d’un nouveau projet en utilisant le code source d’un projet existant. Il semblerait que ce soit devenu le moyen de communication privilégié par des personnes qui participent au développement d’un projet open source, pour exprimer leur divergence de point de vue ou leur frustration suite au chemin emprunté par le projet.

    Le code source des projets open source étant mis à la disposition des développeurs, le fork de ceux-ci se révèle assez simple. L’un des exemples palpant est le nombre de distributions Linux qui existent, dont plusieurs sont nées des divergences lors du développement de celles existantes. C’est le cas notamment de Debian, qui a été forké pour donner naissance à Ubuntu, qui à son tour a vu la naissance d’un embranchement : Linux Mint.

    Si le fork est un élément qui peut se révéler bénéfique pour assurer la relance d’un projet suite à une impasse de son équipe de développement ou pour offrir une alternative suite à des dérives, cette pratique peut être néfaste par la confusion et la dispersion des ressources qu’elle entraine.

    Quand faut-il procéder au fork d’un projet ? Quand ne faut-il pas avoir recours à cette pratique ?

    Les réponses à ces questions se situeraient au niveau des motivations qui ont entrainé le fork d’un projet.

    Pour certains projets, des fork sont nés suite au contrôle d’une entité, c’est notamment le cas des projets LibreOffice et Jenkins, qui sont nés suite à une crise entre Oracle et les communautés open source sur les projets OpenOffice.org et Hubson. Pour d’autres, les fork ont vu le jour pour relancer le développement des projets qui stagnent, c’est le cas de Wordpress qui a vu le jour à cause de l’abandon du moteur de blog b2. Dans ces situations, le fork est justifié et c’est l’unique moyen pour la communauté de continuer à participer et assurer la pérennité de ces projets.

    Des fork peuvent naitre également suite à des changements drastiques entre les versions d’un produit. Ce fut notamment le cas entre GNOME 2 et GNOME 3, qui a entrainé la naissance du bureau MATE, dont l’objectif était de redonner vie à GNOME 2.

    Dans certaines situations, des fork sont nés à cause des conflits entre les développeurs. Parce qu’il s’est fait exclure du projet NetBSD par les autres développeurs, Theo de Raadt a procédé au fork de celui-ci pour créer OpenBSD. Dans ce registre, on peut également citer XFree86, qui a donné naissance X.Org suite à une mésentente entre les développeurs sur la licence à adopter.

    Le fork éloigne-t-il l’open source de son principal ennemi ?

    Si on s’en tient aux déclarations de Richard Stallman, militant du logiciel libre et père du projet GNU, le premier ennemi du logiciel open source n’est rien d’autre que le logiciel propriétaire. Cependant, le fork apporte-t-il un plus à l’open source dans sa bataille contre le logiciel propriétaire ? Si on se limite au nombre important de distributions Linux, et la part de marché de ceux-ci face à Windows, on serait tenté de dire non. Un autre exemple est le fork d’OpenOffice.org en LibreOffice, qui n’a contribué qu’à séparer les utilisateurs de la suite bureautique, sans lui fournir un avantage concurrentiel contre Microsoft Office.


    L’un des aspects clés favorisant l’innovation au sein de l’open source est le développement collaboratif, qui n’est pas, cependant, favorisé par le fork, qui crée une dispersion des ressources. De plus, la multiplication des fork génère une incompatibilité entre les différentes versions et la confusion chez les utilisateurs et les développeurs, qui ont du mal à les supporter dans leur projet. À ce jour, la pléthore de distribution Linux et d’environnement de bureau est devenue un fardeau pour les développeurs, ce qui ne favorise pas leur adoption.

    Loin de vouloir lancer un débat interminable, et conscient du fait que nous nous lançons sur un terrain glissant, le but est de ressortir le bon et mauvais côté du fork et son impact sur l’open source, au-delà des idéologies.

    - Historique de Wikipedia sur les fork



    Source
     

Partager cette page