Le Rayon UX

La radiographie du Web en temps presque réel / thème en chantier (je m'appelle Teuse)

Github a-t-il tué les communautés open source ?

Cet article est le fruit de mes réflexions sur le mode de fonctionnement de Github, forge de développement sociale, et de l’association Ruby France.

Le mouvement open source dans son ensemble est un amusant fourmillement de contradiction (mal) assumées. Il se veut innovant mais repose d’abord sur une économie de substitution. Il prône la décentralisation mais les projets libres fonctionnent selon un mode monolithique à faire pleurer de joie dans leur tombe les dirigeants successifs de l’URSS. Enfin, il repose sur une trompeuse égalité entre les contributeurs tout en reposant sur les mêmes bases que le système féodal au Moyen-Âge. Je ne porterai pas de jugements sur le bien fondé de ce fonctionnement, mais ça fait juste sourire au vu des revendications affichées.

Un mode de fonctionnement vertical

Les projets libres et open source reposent tous sur le même fonctionnement. Une équipe de personnes, souvent des développeurs, tient les clés du projet. Cela se traduit par les choix stratégiques et les droits en écriture sur les sources du projet. Le reste de la communauté s’organise entre sympathisants, utilisateurs et contributeurs. Ces derniers font remonter leurs apports à la core team qui décide ou non de les intégrer au projet, et ainsi de les mettre en lumière. Mais rien qui ne touche au coeur du projet ne peut se faire ou être mis en lumière sans leur aval. S’ensuivent d’inévitables trolls sur les listes de discussions entre contributeurs reconnus mais non membres de la core team et ces derniers.

Ce mode de fonctionnement se rapproche plus de celui des partis politiques dans lesquels différents courants s’expriment, mais qui s’exprime en tant qu’entité selon une ligne définie par le comité politique.

Une application exemplaire de l’esprit féodal

Le fonctionnement interne des projets open source repose sur les bases de la relation à l’époque féodale. Les nouveaux mainteneurs sont choisis pour leurs apports au projet, avec l’établissement d’un lien de confiance qui permet ou non de donner les droits en écriture sur le projet. À ceci près qu’ils sont exemptés de l’hommage lige, et qu’ils jurent plus fidélité au projet qu’au lead developper. Cela revient à jurer fidélité à la couronne et non au roi, et c’est une différence fondamentale avec le système féodal dont les bases reposent sur la confiance d’homme à homme.

Il existe même un équivalent de la parjure dans le monde de l’open source, c’est le fork.

Forker un projet, c’est récupérer l’existant et monter un contre projet ailleurs. Un projet est généralement forké quand son équipe de développement a cessé de s’en occuper, ou quand des dissensions irrémédiables apparaissent au sein de l’équipe de mainteneurs et de contributeurs du projet. Décider de forker est un acte aux conséquences majeures dans la vie d’un projet libre, et qui n’arrive pas tous les jours, car cela implique la mort potentielle des deux branches du projet : division de l’équipe des contributeurs (et donc des volontaires pour faire avancer le projet), et mise en lumière de plusieurs projets similaires au risque de perdre les utilisateurs… Les discussions qui trainent depuis des mois sur le fait de forker Redmine ou non, avec toutes les conséquences que cela pourrait avoir en sont un exemple parmi d’autres.

Github, le coup de pied dans la fourmilière

Github est une forge de développement basée sur Git pour la technologie et sur le fonctionnement des réseaux sociaux pour l’esprit apparue début 2008. Son interface très conviviale, l’aspect social qui donne très facilement de la visibilité aux projets et l’intégration d’une multitude de services lui ont très rapidement donné une popularité sans précédent depuis les premiers jours de Sourceforge.

Mais mine de rien, Github vient aussi donner un grand coup de pied dans le fonctionnement des projets open source, au risque de détruire le système traditionnel.

Là où le système traditionnel voulait que chaque contributeur télécharge les sources du projet dans son coin, puis pousse discrètement ses modifications à la core team, Github repose sur un fork préliminaire du projet. Le fork est même encouragé puisqu’il se fait d’un simple clic de souris sur la page principale du projet.

Le principe du fork par défaut tient de la nature décentralisée du système de gestion de configuration Git. Contrairement à CVS ou Subversion, le simple fait de télécharger les sources permet de commiter localement. Simplement, les droits de commit sur le projet d’origine ne sont pas possible. Github crée autant de projets d’origine qu’il y a d’utilisateurs voulant y travailler, chaque fork est associé à son créateur, et sa page d’accueil Github comporte une mention du projet d’origine.

Les conséquences sont multiples :

Toute personne forkant le projet devient publiquement de facto le leader de son projet portant le même nom que l’original. Les autres utilisateurs de Github peuvent décider de suivre ce fork au lieu du projet original, voire suivre plusieurs versions d’un même projet.

Tous les commits sur les forks poussés sur Github sont publics. Cela signifie qu’un fork ayant une activité supérieure ou prenant une direction différente de celle du projet père pourra attirer une partie de la communauté, diluant cette dernière en autant de communautés qu’il existe de forks.

Conclusion

Le mode de fonctionnement vertical n’est pas fondamentalement mauvais, bien au contraire. Les grands projets open source se sont tous bâtis autour de leaders charismatiques. Sans ces personnes, il n’y aurait pas eu de communauté, aussi le produit fut-il. L’avantage du despotisme éclairé, pour rester dans les références de la philosophie politique est au moins de faire avancer les choses là où la démocratie est essentiellement basée sur le cause toujours (Coluche).

Github a permis à de nombreux projets open source mineurs de se donner une visibilité inespérée. Le système de fork extrêmement simple permet d’attirer les contributions de manière beaucoup plus naturelle et informelle que le système vertical traditionnel. Mais cela risque de se faire au prix des communautés de contributeurs qui permettent à un projet de se développer.

  • Par Palleas 27/01/2011 at 13h31

    Je suis d’accord avec toi sur au moins un point, c’est sur le coté “simple” de forker un projet sur github. Le fork d’un projet est justement trop simple puisque les gens voient un projet cool, le fork et ne commit jamais dessus. J’avoue que ça me dépasse un peu, peut-être que c’est hype d’avoir marqué Symfony2 sur sa page github…

  • Par Yaf 27/01/2011 at 13h51

    Je suis sur ma faim ! J’ai lu dans le chapeau : “et de l’association Ruby France.”. Bien que je comprenne un peu entre les lignes en quoi cela concerne l’asso, j’avoue que j’aurais aimé le lire plus clairement :-p

    Très bon billet sinon, c’est effectivement un boulversement dans le monde opensource. Peut-être pour le meilleur ?

  • Par Jean-Baptiste Emanuel ZORG 27/01/2011 at 14h26

    Je ferai une distinction entre grand projet open source et petit projet/module/plugin ou autre. Pour les grands projets si un fork est suivit c’est qui doit l’être en cela GitHub est génial, pas de despotisme trop souvent subit à tord dans le monde libre. Pour les petits projets/modules/plugins la modification simple et rapide permet une amélioration considérable, évitant certains de mourir, car on est souvent amené a développer un plugin a un moment donné et ne pas forcement le maintenir par la suite. Les requests sur le projet initiale permettant au propriétaire d’inclure facilement et rapidement la modification/amélioration/correction et si il ne le fait pas le flambeau est naturellement transmis au dernier forker, c’est réellement un système communautaire efficace ou chacun peut pleinement jouer son rôle.

  • Par nojhan 27/01/2011 at 16h05

    Sauf qu’il y a une différence entre avoir le code source d’un logiciel quelque part et en faire un fork. Git permet techniquement de faire un fork plus facilement, mais uniquement du point de vue du code. Or, comme tu le soulignes, un projet de logiciel libre, c’est plus qu’un code : c’est une marque, et la communauté qui va avec.

    Parfois, la marque est explicite (Mozilla), parfois associée à un leader (Linux), parfois à une reconnaissance (X.org), etc. Avoir une branche du code ne fait en rien un fork réussi, c’est arriver à se faire une place dans les média qui est la clef.

  • Par NiKo 27/01/2011 at 17h08

    Ce qui est bien avec toi, c’est que tu écris les billets que j’ai la flemme d’écrire, en mieux. Kudos.

  • Par mat 27/01/2011 at 17h35

    Je pense l’exact contraire. Et ce pour plusieurs raisons (quand je parle de github dans mon texte, ca vaut aussi pour bitbucket et compagnie, c’est un tout). Principalement: La facilité avec laquelle les forks sont faits sur github, ca permet surtout d’avoir plus de contributions, et de les intégrer plus facilement ! Je suis un certain nombre de projets, j’en regarde d’autres du coin de l’oeil sans les suivre vraiment, et ce que je constate, c’est que pour pas mal d’entre eux la majorité des contributions viennent de forks. En fait, je suis bien placé pour en parler, j’avais fait quelques petites contributions à des projets (je ne compte pas les projets dont je faisais partie de l’équipe) avant, et bah depuis github, j’ai fait des patches pour une demi-douzaine de trucs en un an, dont une partie ont déjà été reversés dans les projets originaux, sans que je ne demande rien, juste parce-que les mainteneurs l’ont vu sur mes forks !

    Comme dit nojhan (PS: chiant à lire le noir sur bleu foncé des titres des commentaires) les forks sur github sont techniques, pas idéologiques. Github a en fait complètement changé le terme “fork”. On peut facilement voir quel est le projet original sur une page d’un fork, et les commits publics et faciles d’accès renforcent ca d’ailleurs - on voit tout de suite un fork-quasi immobile/dont le code ne vient pas du propriétaire du fork. Il est difficile de confondre.

  • Par Nicolas Chambrier 27/01/2011 at 18h03

    Je pense que la “communauté de contributeurs”, si elle est vraiment une communauté, est construite autour d’autre chose que le simple droit de commiter.

    Cette communauté se crée autour des listes de discussion internes à un projet, et je ne pense pas que ce concept soit mis en danger d’une quelconque manière. GitHub simplifie les contributions ponctuelles, mais les contributeurs “habitués” ne perdent absolument pas la notion de communauté, puisqu’elle existe à différents niveaux : discussion sur l’évolution du projet, sur la pertinence d’accepter ou non une pull request, etc… Autant de discussions qui seront finalement tranchées par le propriétaire du dépot “origin” qui est notre cher dictateur bienveillant.

    Bref, je ne trouve pas que le système soit particulièrement remis en cause, juste les outils qui ne marchent plus exactement dans le même sens ;)

  • Par Pierre Bertet 27/01/2011 at 18h31

    Tout à fait d’accord avec Mat, les « forks » sur github n’ont rien des forks comme on les entend habituellement avec les projets open-source. Il s’agit simplement de « forker » le code (et uniquement le code) à un moment donné, le but étant de réintégrer les modifications dans le dépôt principal une fois que l’auteur du « fork » en a fait la demande. Des patches quoi.

    Je pense que l’incompréhension vient simplement du fait que les non-anglophones associent immédiatement ce mot à la séparation d’un projet open-source, alors que dans le cas présent, il ne s’agit que de la manière dont Git (et les DVCS en général) fonctionnent : on prend une version, on la modifie de son côté, puis on la réintègre.

  • Par Guillaume Laurent 27/01/2011 at 19h30

    Tu décris simplement le mode de fonctionnement des VCS distribués (git et mercurial sont les deux plus connus) :-). Rien à voir avec un fork.

  • Par Alban 27/01/2011 at 22h28

    Le titre aurait pu être “Amalgames et confusions”. En particulier autour du mot “fork” qui n’a évidemment pas le même sens quand il désigne la fonction de GitHub que lorsqu’il est utilisé vis à vis qu’une communauté.

    Au final, on s’approche du contre-sens. Car GitHub facilite la vie d’une multitude de communautés du libre. J’imagine qu’elles ont plus d’énergie à consacrer à leurs cohésions.

    En revanche, GitHub change les usages. Son usage est centré sur l’utilisateur, l’individu. Contrairement aux forges qui l’ont précédées jusque là (orientées sur les projets). Cela dé ou restructure certainement différemment les dites communautés.

    Dommage …

  • Par joan 28/01/2011 at 14h00

    Le fait d’avoir une copie du repository en local, y compris l’historique, ne constitue pas un fork du Projet, juste des sources… La différence est de taille, quand il y a un vrai fork, il faut forker la communauté : le site web, le forum/mailing list, le bug tracker, etc. Quand on forke, on perd toutes ces infos accumulées au cours du projet.

    L’apport des DVCS pour moi est principalement au niveau de la pérennité des sources : Même si le serveur principal ferme, tous les devs ont une version complète du repo avec l’historique. De quoi vraiment repartir du bon pied. Avoir une copie entière du repo est beaucoup plus rassurant pour moi.

    Ce qu’il faudrait maintenant, c’est une techno permettant de télécharger l’historique des messages d’une board pour la reconstruire ailleurs. Là on aura atteint la forkabilité maximale, et on sera dans une situation encore plus saine. Impossible de fonctionner en mode féodal quand le projet peut être réellement relancé ailleurs à tout moment.

  • Par Creak 29/01/2011 at 16h54

    Entièrement d’accord avec ces trois derniers commentaires (et donc pas vraiment d’accord avec ce billet). Si faute il y avait, il faudrait la faire incomber à git, qui permet en une seule commande simplissime (git clone) de “forker” un projet. Or si cette commande existe ce n’est pas dans le but de scinder les communautés open-source, mais de donner le pouvoir à n’importe qui de participer à un projet, avec ou sans la volonté des grands maîtres. “git clone” est d’ailleurs la première commande obligatoire pour quiconque voulant participer à un projet.

  • Par Creak 29/01/2011 at 16h57

    Oups, il y a eu quelques messages entre temps (oui ça faisait longtemps que mon firefox était ouvert). Je parlais des commentaires de mat, Nicolas Chambrier et Pierre Bertet.

  • Par Michael 11/02/2011 at 11h14

    Je pense que le jour ou un gros projet ( kde, gnome, python, le kernel ) passera à un mode “github”, ou le jour ou un project d’assez grande envergure sur github ( comme puppet par exemple ) arreteras d’avoir un mode vertical, on pourras en effet se poser la question.

    La, ce que je vois, c’est que le kernel est toujours aussi vertical ( et pourtant, c’est bien le projet à l’origine de git ), qu’un projet, c’est pas juste du code, c’est aussi de la coordination, de la traduction ( avec relecture pour un minimum de cohérence ), de la documentation, du support, de la representation lors des evenements.

    Donc à moins de montrer au moins une communauté opensource tué par Github, je pense pas qu’on puisse répondre par l’affirmative à la question du titre.

Commentaire Github a-t-il tué les communautés open source ?