Fork, le serpent qui se mord la queue

Le monde du logiciel libre est vaste et c'est sans doute la force mais aussi le point faible de ce milieu. Quand j'ai un besoin d'une fonctionnalité, je prend le temps de faire le tour des solutions logiciels qui la comblent. Celle qui me conviendra le plus sera bien sur la solution retenue. Pour rentrer plus rapidement dans le sujet, j'ai envie de taper un peu sur une mode qui s'étend trop rapidement : le fork.

Le fork consiste à récupérer les sources d'un projet et de faire son propre projet avec (modulo des modifs). Dans l'absolu c'est génial et c'est l'essence même du logiciel libre : prendre, modifier et éventuellement publier. Je trouve ça parfait quand il s'agit de hacker pour un besoin précis. Je trouve ça aussi génial quand l'objectif et de vraiment modifier le système et de partir dans une autre optique que le projet initial. Seulement je trouve ça débile de forker un projet quand l'effort de développement pourrait être mutualisé. Quel est l'intérêt d'avoir deux équipes de dev qui font presque la même chose, l'une se reposant sur l'autre, sans une résultante commune des travaux ? Quand je vois des projets comme CrunchBang (un fork de Debian) qui ne fourni qu'une simple configuration d'OpenBox, ça me fait mal aux fesses : pourquoi ne pas faire un package qui pourrait s'étendre à d'autres distributions ? Comptez le nombre impressionnant de distributions Linux qui sont des forks d'Ubuntu et qui ne servent à rien, vous allez prendre peur (XUbuntu, Xubuntu, FluxBuntu, PureOS, etc.).

C'est vraiment lassant de voir arriver des forks alors que leurs développeurs pourraient simplement contribuer vers l'UpStream...

« Fork » n'est pas synonyme de « contribution » !