[Réflexion] Open Source, Github et centralisation

Tags: Réflexion Open Source Github Centralisation CHATONS


Bonjour à tous !

Aujourd’hui, on va parler d’un sujet qui commence de plus en plus à me questionner. Peut-être que le titre de l’article est du chinois pour certains d’entre vous. Pour cela, comme d’habitude, on va essayer d’expliquer les termes pas forcément connus du grand public avant de pouvoir en parler. Si vous êtes un expert, passez directement à la troisième partie de l’article.

Open Source, de quoi parles-tu ?

Une fois n’est pas coutume, on va citer Wikipédia qui nous explique tout si bien !

La désignation Open Source, ou « code source ouvert », s’applique aux logiciels (et s’étend maintenant aux œuvres de l’esprit) dont la licence respecte des critères précisément établis par l’Open Source Initiative, c’est-à-dire les possibilités de libre redistribution, d’accès au code source et de création de travaux dérivés. Mis à la disposition du grand public, ce code source est généralement le résultat d’une collaboration entre programmeurs.

Logo de l'Open Source
Logo de l'Open Source

La suite de cet article Wikipédia est disponible à cette adresse.

Vous l’aurez donc compris, un logiciel Open Source correspond donc à un logiciel dont le code est accessible à tous. On y retrouve alors ces avantages:

  • On peut auditer le code, c’est à dire inspecter le code et s’assurer qu’il ne s’y passe pas des choses non désirées (envoi de données à notre insu par exemple).
  • On peut hacker (c’est à dire bidouiller ou modifier en français) le code pour l’adapter à nos besoins et envies et même ensuite repartager les modifications effectuées au projet initial.

Par exemple, le gestionnaire de mots de passe que j’utilise est Open Source et disponible ici tout comme son code originel qui est présent à cette adresse.

Qu’est-ce que Github ?

Logo de Github
Logo de Github

Maintenant que vous savez à quoi correspond le terme Open Source, parlons de Github. C’est en fait un service en ligne permettant d’héberger son code (de façon publique ou privée). Le dernier lien du précédent paragraphe est par exemple un lien vers Github.

Lancé en 2008, le service a atteint les 14 millions d’inscrits en 2016 pour 35 millions de dépôts en cette même année. Github a été le premier à généraliser le principe de Fork où chaque personne qui fork un projet devient le propriétaire de la copie du projet.

C’est notamment cette fonctionnalité communautaire qui fait le succès de Github. A l’heure actuelle, il est tellement simple de faire un fork, faire ses modifications et faire une Pull Request (comprendre par là une demande de merge du code (fusion du code) à l’auteur principal) que les nouveaux projets Open Source voient le plus souvent directement le jour sur Github. Cela permet à la communauté de pouvoir être directement impliquée dans le projet et donc de le faire vivre et grandir beaucoup plus rapidement.

Le lien entre l’Open Source et Github

Single Point Of Failure
Single Point Of Failure

Cependant, si Github a du bon, ça reste tout de même une entreprise américaine basée en Californie.

Et le problème vient justement de là: concentrer autant de projets (Open Source ou pas d’ailleurs) sur le service d’une unique entreprise. Qu’adviendra-t’il si l’accès au site devient payant ? Qu’adviendra-t’il si le site décide de changer ces CGU (Conditions Générales d’Utilisation) pour devenir propriétaire du code de tous les projets qu’il héberge ?
Vraiment, le problème est la centralisation de ces projets Open Source dans le même panier. Vous l’aurez compris, j’ai peur que Github devienne un SPOF du monde libre et Open Source. Pour les non connaisseurs, SPOF signifie Single Point of Failure, en clair, si ce point casse, tout casse !

Quelles solutions, quelles alternatives ?

Logo du collectif CHATONS
Logo du collectif CHATONS

Selon moi, la solution la plus simple serait de se retourner vers une instance de serveur git géré par une association à but non lucratif ou de l’héberger soi-même.
On retrouve par exemple l’instance Framagit géré par l’association Framasoft. Mais selon moi, le mieux reste tout de même de posséder sa propre instance ou de rester sur une petite instance. On retrouve par exemple le collectif des CHATONS (Collectif des Hébergeurs Alternatifs, Transparents, Ouverts, Neutres et Solidaires) dont les hébergeurs sont des bénévoles dont l’un des buts est justement d’aller à l’encontre de cette centralisation massive des services par les grosses entreprises.

Parmi les solutions disponibles, on retrouve le très léger Gitea (un fork communautaire de Gogs qui n’est lui maintenu que par une seule personne), Gitlab qui offre peut-être plus de fonctionnalités mais est beaucoup plus lourd (il est délicat de l’héberger sur un Raspberry Pi par exemple) ou encore Bitbucket plus tourné vers le professionnel.

Le paradoxe ?

Le côté paradoxal de la chose est que certaines alternatives à Github sont développées sous Github justement. Gitlab y est en partie, là où Gogs et Gitea y sont entièrement. C’est quand même un comble que Gitlab ne soit pas développé depuis une instance officielle de Gitlab, mais Github permet à la communauté d’y contribuer bien plus facilement (du fait de la taille de celui-ci).

La solution parfaite ?

Selon moi, la solution parfaite serait que les alternatives citées précédemment puissent communiquer entre elles de manière décentralisée à la manière de Mastodon, Peertube ou encore Nextcloud qui utilisent toutes le standard W3C ActivityPub.

Deux instances de Gitea seraient alors en mesure de permettre une collaboration facilitée entre les utilisateurs de chaque instance de manière relativement transparente. On aurait alors le même potentiel communautaire que Github, tout en supprimant les problèmes de centralisation et de SPOF.

Ainsi, si un noeud tombe en panne, tout le reste du réseau pourra tout de même fonctionner, ce qui n’est pas le cas de Github qui avait notamment subi de nombreuses petites pannes durant quelques temps jusqu’en début d’année dernière (source).

Au moment de boucler cet article, mon flux RSS me fait remonter cet article sur Framablog dans lequel est décrit un service de partage de musique décentralisé à l’aide de ActivityPub également. C’est donc l’équivalent de ce dont je pensais: il est pour la musique ce que j’avais pour git en tête. Petite anecdote “marrante”, l’auteur de l’article (qui est également le développeur principal du projet) considère également Github comme un possible SPOF donc il fait son développement sur son instance de Gitlab.

Conclusion

Github est un bon service très reconnu à l’heure actuelle, mais la centralisation de tous ces projets Open Source sur cette plateforme fermée et propriétaire peut rapidement être synonyme de SPOF.

Je ne sais pas s’il est nécessaire de s’alarmer pour autant, mais j’estime qu’il est en revanche important d’être au courant de cette problématique si l’on utilise régulièrement cette plateforme.

N’hésitez pas à me dire en commentaire si vous êtes d’accord ou non avec mon point de vue. Si vous connaissez des services git dont les instances peuvent communiquer entre elles, il peut être également intéressant de partager cela ensemble :)

Commentaires