Temps de lecture 5 min
GitHub est aujourd’hui la plus dynamique forge de développement de logiciels libres. Mais n’y aurait-il pas, dans sa conception même, quelques problèmes de gouvernance et de circulation du code qui menacent l’efficacité, voire la viabilité, des projets ?
Remarque : Pull request, issue, commit… nous présupposons que vous êtes familier avec le vocable GitHub, mais si un gentil lecteur veut nous les préciser dans les commentaires, qu’il/elle n’hésite surtout pas ;)
De la citoyenneté dans le développement de logiciels open source
On Citizenship in Open-source software development
Christophe Maximin – 8 mai 2013 – Blog personnel
(Traduction : ProgVal, Melchisedech, nano-plink, TheCamel, Al + anonymes)
Comment GitHub peut révolutionner la question en donnant le pouvoir aux utilisateurs dans les dépôts auxquels ils contribuent.
TL;DR : En donnant un véritable statut social aux personnes contribuant à un dépôt, GitHub résoudrait le problème des projets-zombies ayant une communauté éparpillée. En permettant à ces citoyens de collaborer réellement les uns avec les autres, et non avec le seul propriétaire, les dépôts seront vivants tant que leur communauté existera, de manière complètement auto-régulée.
L’année a très bien commencé pour GitHub. Après avoir levé cent millions de dollars d’Andreesen-Horowitz et atteint les trois millions d’utilisateurs en janvier (3,4 millions et plus à présent), ils sont sur une dynamique qu’il sera difficile d’arrêter.
Néanmoins, le service a aussi ses défauts, et si certaines personnes pointent du doigt de tous petits problèmes liés aux services et aux applications, le problème que je m’apprête à décrire touche à la nature même de nos interactions sur la plate-forme.
1. État actuel d’un dépôt
Chaque dépôt que vous créez est un petit pays avec une très faible population : 1 habitant, vous, le créateur/roi/commandant suprême.
Même si votre dépôt a des centaines de rapports de bugs créés par d’autres, et des centaines de pull requests, il n’y a qu’une seule personne aux commandes.
Bien sûr, vous pouvez ajouter des collaborateurs à votre dépôt, mais il ne seront que des collaborateurs, des membres du cabinet, choisis juste parce que vous le souhaitez. Bien sûr, dans le cas des organisations, vous pouvez ajouter des co-commandeurs suprêmes.
Mais c’est tout. Vous n’atteindrez probablement pas cinquante collaborateurs/membres ; même si votre dépôt est vraiment populaire, et même si des centaines de personnes y contribuent. Est ce que cela vous parait normal ?
Ce ne serait pas un problème si ce n’était pas la cause de…
2. La fragmentation des dépôts et de leurs fonctionnalités
J’ai vu la chose suivante arriver bien trop souvent :
- Le développeur abandonne graduellement un projet à cause de nouveaux engagements dans sa vie, ou juste parce qu’il n’est plus intéressé. Et donc il regarde les pull requests une fois par mois, peut être. Le projet semble vivant. Il ne l’est pas.
- Le développeur est dépassé par les rapports de bugs et les pull requests qu’il reçoit. Et bien qu’il sache qu’il a une solide communauté autour de ce projet, il ne peut pas juste ajouter quelqu’un comme collaborateur car il devra quand même lire chaque ligne pour être sûr que tout est en ordre. Et donc, il regarde les pull requests une fois par mois, peut être. Le projet semble vivant. Il ne l’est pas vraiment.
Et vous vous dites : « Qui s’en soucie ? N’importe qui peut forker le dépôt et donner une nouvelle vie au projet autre part ! »
Bien entendu, mais combien de fois avez-vous vu cela se faire réellement ?
La plupart du temps, les gens forkent le projet pour régler « le » bug qu’ils voulaient régler, et c’est tout.
Maintenant, si vingt personnes agissent de la sorte, cela devient une vraie tragédie : le projet est en fait encore mis à jour, mais à vingt autres endroits. Vous devrez fusionner les commits de 20 dépôts différents pour être à jour de toutes les nouvelles choses cools que vous pouvez faire avec le projet. Mais vous ne le ferez jamais. Certains forks sont incompatibles de toute façon.
D’autre part, comme le projet « semble vivant », personne ne se presse pour essayer de le remplacer. La léthargie se poursuit alors encore et encore, et va créer la confusion chez n’importe quel nouveau venu quant à l’état du projet, sur l’emplacement des dernières mises à jour, et sur leur éventuelle acceptation par la communauté.
Je ne vais pas donner de noms (ce n’est pas bien de pointer du doigt publiquement) , mais je suis sûr que vous voyez à quoi je fais référence.
3. Le pouvoir au peuple, le pouvoir à la cité
Sans entrer dans un débat sur les multiples définitions du mot citoyenneté, vous trouverez ici une liste de quelques fonctionnalités qui en feront une réalité. Rien de ce qui est listé ici n’est absolu, et ce sera à l’administrateur de définir les règles.
- Tout le monde peut voter pour une issue.
- Tout le monde peut voter pour une pull request, avec un merge automatique quand une majorité (ou quelque chose d’autre à définir) est atteinte.
- Les citoyens se voient attribuer des « points de karma » suivant les votes positifs ou négatifs qu’ils reçoivent sur leurs commits et leurs réponses aux issues. Les citoyens ont un total de points pour ce dépôt, et pour le reste de GitHub.
- Tous les commits qui sont approuvés par le peuple vont dans un branche spécifique préfixée « par_le_peuple_* » .
- Les administrateurs ont toujours le droit de veto sur ce qu’ils veulent, et peuvent complètement couper ce mode « auto-pilote » .
Conclusion
Il est temps que les gens qui contribuent à des projets acquièrent enfin une réelle existence. Il n’y a vraiment rien à perdre, et cela semble pour moi être une évolution naturelle et inévitable de toute façon.
La question est : combien de temps devrons nous attendre ?
mart-e
Si je suis d’accord sur le problème, je ne suis pas sûr que la solution proposée le réglerait. Le problème est que Github est construit sur cette base personne -> projet. L’url est d’ailleurs http://github.com/MOI/MONAPP. Il est beaucoup plus facile de trouver tous les projets d’une personne que toutes les personnes travaillant sur un projet. De même quand j’arrive sur un projet, j’ai du mal à savoir s’il s’agit du projet « originel » ou d’un fork.
D’ailleurs, si je veux corriger une typo dans un code, je dois commencer par forker le projet, faire ma modification et puis ramener le changement dans le dépot « mère ».
En opposition gitorious a une approche différente : https://gitorious.org/PROJET/DEPOT. Une application n’est plus liée à un utilisateur mais à un projet global. Si jamais le propriétaire d’un projet n’a plus le temps, il peut confier sa gestion à quelqu’un d’autre sans tout chambouler. Sous github cela sous-entendrait casser tout (adresse de pull et push différente).
Après cette notion projet vs dépot n’est forcement évidente pour des projets simples. Les gens utilisent utilisent souvent le même nom pour les deux, créant un projet par programme (personnellement, j’ai adopté un projet fourre-tout appelé « scripts and stuff »).
Donc je pense qu’un système fonctionnant sur une architecture comme gitorious serait plus adapté à cette proposition. Avoir un projet abandonné par son propriétaire, maintenu par la communauté mais où l’ancien propriétaire a toujours un droit de vie ou mort (puisque toujours associé à ses projets dans github.com/MOI/VIEUXCODE/) ne me semble pas une bonne idée.
C’était mes deux cents 🙂
Alexis
Je peux voir un problème avec l’approche mentionnée ici: les fonctionnalités les plus demandées ne sont pas nécessairement bénéfiques pour le projet en lui même.
Ce qui peut sembler bon à la majorité des gens / utilisateurs ne l’est pas nécessairement pour le projet en lui même ! On peut souhaiter privilégier un code lisible / compréhensible / simple, ou tout simplement vouloir accomplir une certaine « vision », dans laquelle certaines fonctionnalités n’auraient pas leur place.
Si l’auteur du logiciel ne souhaite pas la mort de son projet, une des manières qui s’est révélée efficace (en tout cas jusqu’à présent) est de créer une organisation et de donner peu à peu du pouvoir aux personnes les plus impliquées, bien sur sur la base de la confiance. Il s’agit ni plus ni moins que d’une méritocratie.
Bien sur, cela n’empêche pas l’auteur de vouloir regarder les « pull requests » et les commits, mais celui-ci n’est plus nécessaire à la vie du projet.
Ceci-dit, j’aime beaucoup l’approche de vote (si on lui enlève la partie « merge automatique ») puisqu’elle permet de prendre la température sur les fonctionnalités souhaitées par la communauté. En pratique cela se passe déjà (même si la forme est différente): les intéressés commentent sur les bugs / pull requests au lieu de voter, ce qui à d’ailleurs l’incidence de provoquer des conversations plus pertinentes que des « +1, -1 ».
philippe
@mart-e
Le fait que les dépôts suivent le modèle http://github.com/MOI/MONAPP ne me gène pas plus que çà. Car il est possible de créer un compte de type « organisation » qui peut donc être le compte du projet (comme gitorious donc) et avec de multiples collaborateurs ayant les même droits de pull,…
Donc après, il est vrai que tout repose sur la volonté de partage du créateur initial du projet. S’il ne veut pas créer une organisation, ni promouvoir au moins quelques personnes en tant que collaborateur, c’est vrai que ça devient problématique et le fork sera couteux.
Ce qui me gène le plus dans Github est que lorsque qu’on fork un dépot, on ne fork que le code source et non pas le wiki, les issues, les pulls request,…
Donc au final on perd beaucoup de choses et le fork de github revient seulement à forker pour contribuer au projet initial (étape imposée par git pour ensuite faire un pull request) et non pas forker un projet pour devenir un autre projet à part. Cela n’est pas facilité et, oui, une nouvelle forge devrait pouvoir permettre cela.
Pour faciliter cela, il faudrait pouvoir avoir accès au dépot git du wiki et de pouvoir le forker également, ainsi que d’avoir un gestion des issues comme permettrait de le faire « Bugs Everywhere » http://bugseverywhere.org/ où le suivi des bugs est fait DANS le dépot du projet. Comme ça, quand on fork le projet, on fork également le suivi des bugs. Et de la même manière, on pourrait (peut-être) mettre les issues, ou dans un autre dépot…
Encolpe
Bof.
La solution est connue : passer à l’utilisation payante de github.