Le monde du libre actuel part en couilles ? Bonus n°4 : vouloir faire « cavalier seul », maladie du logiciel libre ?

Attention, « article vieux con qui pensait que c’était mieux il y a une quinzaine d’années » à suivre. Maintenant que l’annonce a été faite, attaquons le coeur du problème.

Depuis une grosse quinzaine d’années, j’ai pu constater la montée en puissance d’un individualisme qui est contraire à un des fondements du monde libre : la coopération, remplacée par la concurrence à tout crin.

En clair, tout l’opposé qui avait permis au noyau Linux de connaitre sa première version en moins de trois ans après le lancement du projet. J’ai déjà eu l’occasion de parler ad-nauseam des forks compulsifs qui donneront naissance à des projets qui ne vivront parfois que quelques semaines ou quelques mois.

Un des articles que j’ai bien aimé écrire sur cette utilisation abusive du fork date de novembre 2014, auquel je vous renvoie donc la conclusion est la suivante, toujours aussi vraie plus de 4 ans et demi après.

Chacun voit midi à sa porte, et je continuerai de dénoncer les forks compulsifs. Ce n’est pas en ignorant un problème lié à l’abus d’une composante du logiciel libre qu’on le résoudra.

Mais, c’est vrai… Je ne suis que l’emmerdeur de base, l’utilisateur final, somme négligeable au final 🙂

Mais j’ai envie de parler d’une volonté qu’on peut voir de temps à autre, celle de vouloir faire cavalier seul contre le reste du monde libre en espérant imposer son point de vue par la force. Oui, en gros, faire son Microsoft.

Il y a une boîte qui a fait énormément de bien pour la démocratisation du libre qui est l’exemple même de cette politique de cavalier, c’est Canonical. Oui, la maison mère d’Ubuntu. Avant que certaines personnes ne sortent les haches, les torches et les cordes pour me lyncher, je tiens à préciser que j’ai apprécié ce qu’à fait la boite de Mark Shuttleworth durant les années 2004-2009. Depuis c’est moins le cas.

On peut citer au moins trois tentatives pour imposer ses solutions qui se sont viandées. Chronologiquement ?

  1. Upstart (2006-2014)
  2. Unity (2010-2016)
  3. Mir en tant que remplaçant de Wayland (2013-2017)

Revenons sur chacun d’entre eux. Pour upstart, c’était la volonté de remplacer le vieillissant sysVinit. Introduit avec ubuntu 6.10 en octobre 2006, il sera supporté par Canonical jusqu’à la version 15.04. Red Hat l’utilisera pour sa Fedora entre les versions 9 et 15.

Inutile de préciser quel système d’init a remplacé upstart… Bref, un échec cinglant pour Canonical.

Pour Unity, le problème venait du fait que c’était un environnement conçu pour être intimement lié à Ubuntu. Je vous renvoie à mes archives pour montrer à quel point la portabilité n’était pas prévue. Il suffit de voir le nombre de paquets qu’il fallait faire recompiler et rustiner pour faire fonctionner Unity sur Archlinux… Un article rédigé en juillet 2016 vous montre le bazar monstrueux que c’était à l’époque.

Parlons pour finir de Mir. Introduit par Canonical pour proposer son propre successeur à X11 et donc concurrencer Wayland début 2013, il n’avait quasiment aucune chance de s’imposer ailleurs. Si on regarde sur le github du projet, la première version du fichier README.md est claire. On est le 19 décembre 2012.

mir – cross-platform display manager

Mir is a display manager that provides efficient support for graphics coprocessors.

Est-il besoin de traduire ? 🙂

Après l’abandon d’unity pour la Ubuntu 17.10 et l’officialisation de Gnome à la place, et la sortie d’Ubuntu 18.04 LTS, en juillet 2018, le fichier README.md est fortement modifié.

On a alors droit à quelque chose qui montre une volonté de se raccrocher au train Wayland :

Mir is set of libraries for building Wayland based shells.

De concurrent de Wayland, Mir en devient une « implémentation », en quelque sorte. Sacrée descente aux enfers.

On va me dire qu’il y a eu d’autres projets de ce type qui ont existé depuis des années. Mais l’importance de Canonical dans le monde du libre depuis 2004 ont mis en avant les projets « maisons » qui n’ont pas fonctionné. On est loin du cimetière des services et technologies enterrées par Google néanmoins.

Faire cavalier seul dans le monde du libre, ça sert à rien !

20 réflexions sur « Le monde du libre actuel part en couilles ? Bonus n°4 : vouloir faire « cavalier seul », maladie du logiciel libre ? »

  1. je dirai qu’en fait très peu parviennent à faire cavalier seul ,
    depuis pas mal d’année cela évolue très vite dans chaque partie ( compilateur / système / composants système / drivers / environnement / type desktop )

    si on regarde bien , il n’y en a pas beaucoup qui parviennent à tenir en équipe minimum de 2 a 3 développeurs , je prendrai en exemple , solus mais aussi DragonBSD qui continue depuis des années avec son système de fichier Hammer2

    au niveau des developpeurs , bien maitriser le C , cela est de plus en plus difficile , au vue du nombres de lignes en code pour les partie linux

    1. « je dirai qu’en fait très peu parviennent à faire cavalier seul »
      Fred, tu as des statistiques sur les projets linux en solo ?
      Tu as une liste de certains projets effectués en solo ?
      Pour voir l’étendu du phénomène.

  2. Il peut y avoir des forks meilleurs que des distributions. Par exemple une Artix n’as rien a envier a une Manjaro, meme si on se doute que la Manjaro durera plus longtemps car elle a plus de mainteneurs et de soutien mais parfois le vent peut tourner. Tu avais fais une catégorie pour cela: les distributions injustements oubliées qui mettent en évidence les distributions qui ont beaucoup de qualité mais qui n’ont pas pu etre maintenue

  3. Je suis surpris par cet avis: quand Canonical fait quelque chose seul, c’est mal même si c’est utilisé par d’autres (upstart) alors que lorsque c’est Red Hat, c’est bien: Pulse audio ou encore systemd… qui ont ensuite été repris par les autres distributions.
    Autrement dit, on peut faire cavalier seul au départ tant que la communauté peut ensuite l’utiliser. Le début n’est pas important, c’est qu’on en fait après qui compte.

    Quant à Mir, ce n’est plus un projet porté par Canonical, ce qui pourrait expliquer la modification du README puisqu’il n’est plus utilisé pareil (c’est un utilisateur d’Ubuntu Touch qui te le dit).

    1. Le noeud du problème est la portabilité du code. Red Hat fait tout pour que son code soit neutre et portable sur n’importe quelle distribution.

      Si un code est développé par un gros acteur mais avec une vision globale, pas de problème. Upstart a été tué par le développement de systemd qui était au final mieux fini par endroit.

      Des projets comme Unity et Mir était peu ou pas portable. Ce qui a été la raison de leur échec.

      Il est vrai qu’entre 2008 et 2011, Red Hat a utilisé Upstart pour ses Fedora 9 à 14. Mais ils ont préféré ensuite ne pas dépendre de Canonical pour cet élément crucial qu’est le système d’init, avec Fedora 15 et la première version de systemd proposée au grand public.

      Article sur linuxfr pour la Fedora 9 : https://linuxfr.org/news/fedora-9-une-version-sulfureuse

      Article sur linuxfr pour la Fedora 15 : https://linuxfr.org/news/sortie-de-fedora-15-%C2%A0lovelock%C2%A0

      Enfin, la RHEL 6.x qui utilise upstart arrivera en fin de vie en novembre 2020 : https://access.redhat.com/discussions/2399461

      Autant dire qu’Upstart aura pas mal vécu 😉

      1. Je ne comprends pas le passage sur Upstart et le besoin d’indépendance à Canonical qui a fait que Red Hat a développé systemd. En effet, Upstart est publié sous GPL v2 donc Canonical n’avait pas la main sur Upstart… ce qu’on ne peut pas dire sur Mir jusqu’à son « don » à la communauté.

        1. Même si le code d’upstart était sous GPLv2, c’était Canonical qui le développait. Donc RedHat dépendait plus ou moins du bon vouloir de Canonical.

          Quant à Mir, c’est une énorme connerie technique de Canonical.

          1. Tu réinventes un peu l’histoire. Red Hat a contribué avec upstart et ont soutenu son développement. Cependant ils ont identifié les limites, que les développeurs de Canonical ont reconnu, et ont donc insufflé systemd pour corriger les défauts d’upstart qui étaient trop profonds pour être corrigés au fil de l’eau.

            Pour le coup upstart n’était pas un vrai cavalier seul de Canonical, c’était une première bonne esquisse qui aura permis à systemd d’émerger en corrigeant les défauts de jeunesse. D’où le fait que RHEL et Fedora l’ont utilisé quelques temps.

            Ce n’est pas vraiment une histoire de concurrence sur le secteur.

  4. Pour moi, il s’agit de trois situations très différentes.
    Upstart : c’est un cavalier seul, mais pas plus que Pulse Audio ou Systemd. Il était utilisable par d’autres (et l’a d’ailleurs été de nombreuses années). Pour moi Upstart ne rentre pas le cadre de ce que tu voulais critiquer dans ton article.

    Unity : en soit, faire un nouveau desktop n’était pas critiquable, surtout au moment où Gnome semblait se perdre dans des choix ergonomiques difficilement compris par de nombreux utilisateurs. Qu’il se soit révélé difficilement intégrable sur d’autres distributions est en revanche un vrai problème/erreur (je ne sais pas si c’était volontaire ou si cela résultait des choix techniques effectués).

    Mir : difficile de te contredire sur ce cas. Quelle erreur !

    1. Premier point : upstart était une volonté de proposer un init pour remplacer sysVinit. Mais Canonical n’a pas la puissance de feu d’un Red Hat.

      Deuxième point : ergonomiquement, Unity et Gnome Shell partent de la même idée, faire une interface nouvelle génération épurée. Sauf qu’Unity n’a pas été pensé pour être portable.

      Pour Mir, c’est un peu comme Unity dans le domaine de l’environnement bureautique.

  5. Dans le genre je fais cavalier seul, je demande elementaryOs. Et pas forcément pour pantheon, mais pour tout le reste.

    Quand vous regardez le store d’applications d’elementaryOs, en premier lieu, vous avez les applications développés avec leur outils en vala, et qui correspondent à la charte elementaryOs d’un point de vue graphique, et utilitaire (Une application pour un seul et unique usage). En second lieu, vous avez les applications que vous pouvez trouver sur toutes les autres distributions Gnu/Linux.

    Ce qui est dingue, c’est que si je vais sur cette page, https://appcenter.elementary.io/, y’a pas beaucoup d’application que je connais. Presque à la manière d’un Apple, ils cadenassent la distribution sur toute la longueur. Quand la logithèque « maison » sera bien développée, il pourraient presque ne pas afficher les applications mainstream dans le store, mais seraient toujours accessible via le terminal, dépôt Ubuntu oblige.

  6. Petit bémol, RedHat bien qu’initiateur, mainteneur, contribueur, etc… de pleins de projets, ne fait jamais cavalier seul, ils sont entourés d’une pléthore de développeurs

  7. Avant même la portabilité de Unity, la communauté avait déjà fait le choix de ne pas l’accepter par ce que premièrement ca venait de canonical et deuxièmement, la lourdeur sur de vielle ou petites machines et enfin, le fait qu’il fallait patcher gnome dans tout les sens. D’ailleurs, si unity n’était pas portable, c’est clairement la faute aux développeur de gnome qui ont refusés le moindre patch pour que justement, unity puisse être transposable.
    Canonical n’est pas le seul fautif dans cette affaire. La communauté du libre l’est aussi.

    Moi, ayant toujours eu de gros pc, j’ai donc évité la lourdeur de unity.

    Je sais que unity est devenu un projet autonome et j’attend avec la plus grande impatience de pouvoir le retrouver sous forme de shell à installer pour remplacer cette daube de gnome-shell.

    En attendant, je me contente de KDE Neon qui est une très bonne distribution.

    Et sinon, entre wayland et gnome-shell c’est toujours aussi le grand amour? Ca plante toujours le pc aléatoirement ? J’ai un ami sous Fedora < 30 qui s’accommodait du fait que n’importe quant, son pc pouvait planter à cause de soucis entre les deux.

    1. Ah bah merci Xarkam; Je me sentais seul avec les bugs de Wayland et gnome, ne parlons pas des autres DE puisque seul Gnome le supporte pleinement (soit disant)…

      Sinon je suis entièrement d’accord avec ta vision sur unity et canonical, c’est bien les devs de gnome qui n’ont pas voulu le moindre patchs ou ajout de fonctions de la part de canonical, sinon il n’y aurait jamais eu ni unity ni un unity peu portable sur autre chose.

Les commentaires sont fermés.