Plone, le plus gros CMS Libre vient lui aussi de passer sur GitHub. Vous pouvez donc constater la présence de 127 (!) dépôts Git. Ce nombre important vient de la programmation par composant du monde Zope (une fonctionnalité = un composant Python = un dépot Git).

Pourquoi je parle de cette migration en particulier alors que de nombreux projets Libres passent sur GitHub ? Tout simplement car c'est aussi un des plus gros projets Python, langage utilisé par les deux principaux «concurrents» de Git, à savoir Mercurial et Bazaar. Ce choix fait suite à un sondage chez les développeurs pour déterminer la prochaine plateforme d'hébergement (3 réponses possibles : oui, neutre, non) :

• Héberger son prore serveur Git : 10, 36, 33
• Héberger son prore serveur Hg : 8, 18, 53
• Héberger son prore serveur Bzr : 1, 3, 75
• Sur GitHub : 46, 21, 12
• Sur Bitbucket : 8, 18, 53
• Sur Launchpad : 4, 6, 69
• Continuer avec son propre serveur SVN : 28, 30, 21

Ce résultat est révélateur sur plusieurs points :

• Un rejet absolu de Bzr. Personne n'en veut à part quatre personnes.
• Un rejet massif de Launchpad et dans une moindre mesure de Bitbucket (plutôt étonnant).
• Peu de gens sont pour héberger un serveur DVCS, ce qui me semble encore une fois assez étonnant. Il est facile par exemple d'administrer un serveur Hg. Plus un problème de méconnaissance ?
• Plus de la moitié des votants sont en faveur de GitHub, sans être un plébiscite.

La conclusion qui semble se dégager de cette enquête est que c'est encore une fois GitHub qui fait pencher la balance vers Git, et non l'inverse. D'autant plus que choisir Git signifie faire une croix sur la possibilité pour un développeur Python de coder facilement des extensions Mercurial, atout non négligeable quand on gère un projet.

Le ticket 2454 est maintenant fermé. Nommé native git support, c'était le ticket le plus demandé (starred) par les utilisateurs. Un peu plus de 2 ans après le support de Mercurial, Google Code supporte donc Git. Cela signifie que les 3 plus gros hébergeurs de code (Sourceforge, Google Code et GitHub) supportent maitenant notre DVCS préféré. Cela signifie aussi que l'avenir s'assombrie pour Mercurial, qui se retrouve (presque) dans la même situation que Bzr, avec un seul hébergeur dépendant important. Terme mal choisi pour désigner un hébergeur qui s'appuie uniquement sur une techno, en l'occurence Bitbucket (Launchpad pour Bzr).

Pourquoi ce changement alors que rien ne semblait prévu ? Je vois deux raisons, l'une technique et l'autre marketing.

L'argument technique

Comme le dit très bien Shawn Pearce, développeur Git, mainteneur des projets Gerrit et JGit (ré-implentation de Git en Java, utilisé par Gerrit et Eclipse notamment), sur la liste de diffusion, Git supporte depuis la version 1.6.6 le protocole smart http. Ce dernier gère bien mieux le protocole http sur lequel Google Code s'appuie massivement. Ce qui a ouvert la voie, il suffisait (hum) ensuite de modifier Git pour gérer l'infrastructure Google. Si cela vous intéresse, jeter un oeil sur la video Google I/O 2009 - Mercurial on BigTable qui explique cette même modification avec Mercurial. Une vidéo similaire devrait sortir pour Git (chouette !).

Chose étonnante, d'après Dave Borowitz, Google code n'utilise pas JGit mais Dulwich, codé en Python. Je suis curieux de connaitre les raisons de ce choix (Shawn avait averti que ce n'était pas JGit mais n'étant pas le responsable du projet, il ne voulait pas en dire plus).

L'argument marketing

La montée en puissance de GitHub ne fait aucun doute, cet article le montre fort bien : entre janvier et mai 2011, le nombre de commits sur GitHub représente le total des commits de Sourceforge, Google Code et CodePlex réunis. Même si ce chiffre est à prendre avec de grosses pincettes, les DVCS poussent au commit unitaire donc à en produire bien plus, c'est un chiffre intéressant (le nombre de lignes de code serait lui significatif).

Et chose intéressante, on retrouve le C++ et Java en tête, cela laisse entendre que ces communautés ont eux aussi (au moins partiellement) basculées sur GitHub (après les communautés Ruby, Javascript et Python).

Pour conclure

Redmonk dit que GitHub est le nouveau centre de gravité, les chiffres le prouvent, et je trouve cela très bien. D'un coté, les développeurs sont poussés à ne plus utiliser des hébergements 1.0 (et zut, je succombe moi aussi à cette mode débile). De l'autre, il pousse les hébergeurs à augmenter drastiquement la qualité. Et on ne va pas s'en plaindre !

Si la plupart des gens considèrent GitHub comme une superbe plateforme d'hébergement de code, beaucoup sont encore dubitatifs sur la délégation des tickets (bug et/ou fonctionnalité), et préfèrent utiliser Trac, Redmine ou JIRA. Il est donc intéressant d'apprendre que le projet Ruby on Rails (qui pour l'anecdote, est hébergé depuis le premier jour de GitHub) utilise officiellement GitHub pour ses tickets de bugs.

Le retour d'expérience va donc être très intéressant. Et sans nul doute, les GitHubbers (les développeurs de GitHub) seront très sensibles et réactifs aux remarques et retours, étant eux mêmes des utilisateurs de RoR.

GitHub vient de sortir le pendant du merge en 1 click. Alors que l'amélioration précédente était à destination du mainteneur, celle ci est à destination du collaborateur. Ce dernier peut maintenant modifier un fichier d'un dépôt quelconque (sans droit d'écriture donc) en passant par le site web :

Et proposer un pull request dans la foulée :

Cela veut dire qu'une modification peut être faites et proposer en... 3 clicks ! Plus d'excuse pour proposer cette petite correction de typo que vous avez vu, ou cette documentation pas très claire.

Note : bien sur, rien de magique la dedans. GitHub fork le projet, applique votre modification (commit), et vous ouvre la fenêtre du pull request. Pas magique certes, mais bien pratique :).

GitHub vient de sortir une fonctionnalité surement attendue par beaucoup : la possibilité de fusionner (merger) facilement une demande de récupération de code (pull request) !

Rappel du workflow

Si je souhaite faire des modifications sur un projet, le workflow par défaut de GitHub me demande de suivre ces étapes :

1. Je créé une version personnelle de ce projet sur GitHub, afin d'avoir le droit d'écriture (fork dans la terminologie GitHub).

2. Je clone ma version GitHub sur ma machine (git clone).

3. Je code, je code, je code.

4. Une fois satisfait, je pousse mes modifications sur mon fork GitHub (git push).

5. Je fais un pull request, en donnant toutes les informations pertinentes au mainteneur.

C'est à ce moment la que vous demandez au mainteneur du projet de récupérer votre code pour le lire, le commenter et l'intégrer s'il est satisfait de vos modifications.

Coté mainteneur

Depuis quelques mois, il peut directement commenter le code dans un pull request, vous demander de plus amples informations, ou discuter avec d'autres personnes. Bref, il pouvait tout faire sur l'interface Web sauf pour intégrer le code. Il devait récupérer votre code (git pull) dans une branche et fusionner (git merge) avec la méthode «traditionnelle», autrement dit avec Git.

La nouveauté

Plus maintenant ! Si le mainteneur le souhaite, il peut directement faire une fusion en cliquant sur un bouton :

Si la fusion se passe mal :

Il suffit donc d'un seul click pour fusionner et fermer la demande.

Note : le merge est un non fast-forward (on modélise donc la fusion, cf ma présentation) et le message de merge indique le nombre, la source et le titre du pull request :

Conclusion

Cette fonctionnalité prend tout son sens depuis les améliorations sur l'interface, puisque l'on peut visualiser le code, commenter le code, discuter autour du code... et maintenant fusionner le code. C'est un pas en avant vers la simplicité et rend GitHub plus attrayant pour les personnes qui ne sont pas encore des «Git-Fu».

GitHub vient d’annoncer des chiffres impressionnants : 1.1 million de projets et 900 000 Gists. Et si vous êtes bon en calcul mental, vous savez donc que GitHub à dépassé les 2 millions de dépôts Git. Mais plus intéressant, 70% des projets sont récents (moins d'un an), ce qui fait environ 4500 nouveau projet par jour, pas mal ! Et d’après les estimations internes, le million d'utilisateurs sera atteint le 11 septembre 2011.

Ces chiffres confortent GitHub comme plateforme d'hébergement de référence. Et par la même occasion, la montée en puissance (comme dirait Domenech) de Git. Il parait assez clair à mes yeux que ce dernier soit rapidement l'outil de gestion de source numéro 1 dans le monde du Logiciel Libre.

Mais gardez un oeil sur Hg ou Bzr, il est important de maitriser plusieurs outils, rien que pour satisfaire, je ne doute pas, votre appétit de connaissance :).

Dans mon précédent article sur GitHub, je disais que la gestion de ticket était «simple». Et bien, les GitHubbers doivent me lire (je ne vois pas d’autres explications) car GitHub vient de lancer Issue 2.0, le nouveau système de gestion de ticket !

Une issue (que l’on peut traduire par «problème» mais je préfère le mot «ticket») ressemble maintenant à ça :

Vous pouvez constater plusieurs changements comme les personnes concernées (en bas), la délégation du ticket à une personne ou les milestones («étapes» en français). Voyons maintenant les nouveautés plus en détail.

Assigner un ticket

Vous pouvez assigner un ticket à un utilisateur GitHub.

Les milestones

Créer des milestones est une étape (ah-ah, oui je sais avoir de l'humour) importante pour disposer d'un outil de gestion de ticket efficace, permettant de définir des releases (ticket 10, 11 et 20 pour la future v1.2 par exemple). Un ticket pouvant porter sur une correction de bug, une nouvelle fonctionnalité ou tout autre sujet (documentation, infra...). C'est pour cela que le terme issue tracker est plus juste que bug tracker.

Historique des états d'un ticket

On peut maintenant visualiser le changement d'état d'un ticket au cours du temps.

Navigation plus aisée

Plus simple et agréable, vous pouvez filtrer par label ou milestone. Ou alors voir vos tickets ou ceux ou vous êtes mentionné.

Vous pouvez aussi modifier plusieurs tickets à la fois («mass-edit» en anglais).

Enfin une recherche rapide («quickseach» en anglais) affiche les premiers résultats en quasi temps réel fait son apparition.

Commit + ticket

Point intéressant, si vous nommez le numéro d'un ticket dans le message de commit, ce dernier apparaitra sur le ticket.

Mieux, vous pouvez fermer un ticket directement, en utilisation le mot clé fixes #xxxx (ou fixed, fix, closes, close ou closed).

email + ticket

Autre amélioration notable, vous pouvez directement répondre par mail quand vous recevez une notification.

Raccourci clavier

On peut maintenant se passer de la souris :).

PJAX

Les écrans sont en PJAX, une techno GitHub permettant de ne recharger qu'une partie de la page et qui va être généraliser un peu partout (demande Firefox 4 ou un Chrome récent, mais je présume que cela fonctionne avec Opéra et Safari. Non IE n'est pas un navigateur moderne).

Conclusion

Les améliorations sont notables et redonnent des couleurs à la partie qui était, à mes yeux, la moins avancée du site en terme d'utilisabilité et surtout de fonctionnalités. L'arrivée des milestones permet de définir une roadmap, ce qui est toujours intéressant. Et enfin, la manipulation d'un ticket avec un message de commit va simplifier le travail de gestion de projet. Espérons que GitHub continue sur cette voie, par exemple en permettant de créer automatiquement un ticket avec un message de commit particulier sur un fork.

On me pose souvent cette question : « Git est il utilisé et quelle est la taille de sa communauté ? ». Ma réponse se résume souvent à donner l'url de GitHub. Les chiffres parlent d'eux mêmes :

• Plus d'un million de dépôt, dont 60% sont des projets.

• Plus de 400 000 utilisateurs.

• Dans les 1000 sites parmi les plus visités avec 600 000 visiteurs uniques par jour.

• Des pointes à plus de 400 000 commits par jour !

GitHub apporte une visibilité importante à Git, comme j'ai pu l'entendre plusieurs fois : «Je me suis mis à Git à cause de GitHub !». Mais pourquoi l'utiliser ?

Au lancement du projet, au milieu de l'année 2008, le leader de l'hébergement de projets Libres s'appelle Sourceforge. Ce dernier existe depuis 1999 et a pour but d'héberger gratuitement tous ceux qui désirent une infrastructure solide, avec CVS (on est en 99 ne l'oubliez pas :)), liste de diffusion, et site web. Mais ce dernier vieillit mal : aspect très «20ème siècle», pas de DVCS (seulement CVS et SVN), et un forum qui tuerait sur place un ergonome... Il est possible néanmoins d'héberger son dépôt Git à l'époque avec repo.or.cz, mais il offre lui aussi un design vraiment basique et des fonctionnalités limitées. Et surtout, il n'existe aucune possibilité d'avoir des dépôts privés.

D’où l'idée de proposer un hébergement Git de qualité, avec un design clair, gratuit pour les projets Libres mais permettant aussi les projets privés. Ils ont donc décider de créer (sur leur temps libre, l'utilisation de Git à cette époque est balbutiante) un site simple et efficace. Le succès est foudroyant, avec 10 000 projets en moins de 8 mois. Et plus important, le service est rapidement rentable avec les offres d'hébergement privés. Les fondateurs passent rapidement de bénévoles à employés temps plein, et embauchent quelques personnes, dont @chacon, qui se démène pour parler de Git (1 livre, 1 pdf, 3 sites dont le site officiel, des formations et quelques dizaines de présentations à son actif depuis 3 ans). Pour l'anecdote, GitHub embauche massivement depuis le début 2011 (15 postes).

Il faut noter que le projet Ruby on Rails fut hébergé dés le 1er jour, faisant ainsi basculer la communauté Ruby dans l'escarcelle de Git (fin 2008, 36% des projets sont en Ruby). Les fondateurs étant des Rubyistes, la majorité du site est codé en Ruby (notamment avec du RoR), et je crois que c'est toujours le cas aujourd'hui.

Quelles sont les raisons de ce succès ? Voici quelques éléments de réponses :

• L'hébergement privé, à un prix accessible.

• L'hébergement gratuit, qui permet de tester le service sans aucune limitation d'utilisation. La seule contrainte étant de ne pas pouvoir rendre son dépôt privé.

• Un design clair, élégant et simple. Par exemple , on créé un dépôt en 2 clicks et 4 questions :

• Une page nous récapitule ensuite comment l'utiliser. Moins d'une minute sont nécessaire pour démarrer. L'ergonomie fait, comme souvent, la différence.

• Utiliser un projet déja existant est encore plus simple puisque la commande Git vous est donnée (protocoles ssh, https et git).

• Un moteur de recherche puissant disposant de 20 mots clé.

• Utilisation des clés ssh. Une fois copiées sur le site, plus besoin de s'identifier. Un jeton (token) est utilisable à la place d'un mot de passe.

• Une documentation abondante, sur le fonctionnement du site comme sur Git.

• La présence de Gist, permettant de partager des données (code ou autre) simplement et rapidement. Le tout géré par (et donc utilisable avec) Git bien sûr. Cela permet aussi de travailler à plusieurs sans être dans un projet particulier.

• La possibilité d'avoir un wiki, qui est un dépôt Git :

• Un bugtracker (un poil simpliste mais généralement suffisant) :

• Un outil de revue de code :

• La gestion des notes :

• Une API complète, avec des wrappers disponibles dans plusieurs langages.

• L'utilisation de Markdown un peu partout sur le site comme pour le rendu plus riche de document texte.

• La disponibilité de flux RSS pour les différents historiques.

• Des hooks pour plugger votre projet (sur un bugtracker, un outil d'intégration continue, de gestion de projet, Twitter...).

• Visualisation graphique des branches :

• Statistiques graphique du projet (nombre de ligne de code impactées dans le temps, langages utilisés...).

• La possibilité de notifier un développeur en mettant son login (@somebody) dans n'importe quelle conversation :

• Un gestionnaire de binaires (où vous pouvez uploader vos propres fichiers en plus de ceux générés automatiquement).

• Et bien sûr, un service rapide et efficace.

Mais si la partie «technique» est importante et fait la différence vis-à-vis des concurrents (il suffit de visiter la page du projet Git sur GitHub avec la page du projet Git sur repo.or.cz), l'aspect le plus important de GitHub est social. C'est sur ce point que GitHub a fait la différence.

GitHub et le «social coding»

Dés sa création (le travail commence fin 2007 pour un lancement officiel en février 2008), GitHub se veux social. Cela signifie que le site facilite grandement la «mise en relation» des développeurs. Fini les sites «à la Sourceforge» où les gens sont cloisonnés dans les projets. Vous pouvez voir la vie du projet avec la «Timeline» et mieux, la suivre :

mais surtout vous pouvez suivre un développeur :

Et cela change tout ! Vous êtes maintenant au courant de toutes ses actions, par exemple des projets qu'il lance dès leur création.

Vous pouvez naviguer dans GitHub par dépôt bien sur, mais aussi par Timeline, mot clé, langage de programmation ou changelog. Vous pouvez vous abonner à un flux RSS de l'activité du projet.

Mais surtout, GitHub tire partie de la philosophie des outils de code décentralisés : chacun peut cloner un projet et le modifier, pour ensuite demander l'intégration de ses modifications. En tant que créateur d'un projet, vous permettez à la terre entière de participer à votre projet, et ceci de manière totalement transparente, permettant de créer rapidement une communauté de développeurs. Et vous communiquez facilement avec les autres, par l'intermédiaire de Gist, du bugtracker, de pull request, du wiki...

Intervenir sur un projet est devenu incroyablement simple :

• En clonant un projet, vous pouvez travailler sur le code en moins d'une minute :

• En faisant un "pull request", vous pouvez contribuer à un projet (notez la discussion qui s'en suit) :

• En éditant le wiki, vous pouvez modifier la documentation projet.

• En créant un issue dans le bugtracker, vous pouvez demander une fonctionnalité ou rapporter un bug.

Quel changement ! Souvenez vous «avant», où il fallait s'abonner à une liste de diffusion, discuter avec les développeurs pour demander comment envoyer ses patchs, voir attendre les droits d'écriture sur le SVN... GitHub exploite à fond la puissance des outils de code décentralisé (DVCS), ou le fork et le merge sont des actions simples et surtout naturelles. Git étant ici favorisé par rapport à Mercurial par sa meilleure gestion des branches et des dépôts distants (ce dernier grignotant néanmoins petit à petit son retard).

Le développeur est mis en avant

Sur GitHub, le développeur a une existence propre. Il est facile de voir ses délots, et plus généralement ses activités. GitHub montre que les projets n'ont pas de vie propre, mais sont animés par des développeurs. C'est la suite logique vers la reconnaissance du rôle de développeur, que le Logiciel Libre avait initié (je suis sûr que vous connaissez le nom du responsable du projet Linux, mais connaissez vous le nom du responsable du projet Windows 7 ?). Vous leur parliez par IRC et par liste de diffusion, vous voyiez leurs annonces sur le blog alors que maintenant vous pouvez simplement visualiser leurs activités et surtout collaborer sans action lourde, comme s'abonner à de multiples liste de diffusion.

La suite logique de cette philosophie est l'extension Linkedin pour GitHub : vous mettez en avant votre code, votre mobilisation dans des projets Libres, votre capacité à gérer un projet...

Conséquences

Son usage est centré sur l’utilisateur, l’individu, contrairement aux «forges« qui l’ont précédées et qui sont orientées sur les projets, cela restructure les communautés. Le système de fork attire les contributions de manière beaucoup plus naturelle et informelle que le système traditionnel. Le mainteneur incluant parfois des modifications sans demander aux contributeurs car il suit les forks de son projet !

Github a permis aussi à de nombreux projets mineurs de se donner une visibilité inespérée, évitant à certains de mourir faute de contributions.

Et enfin, aspect intéressant de la vie du projet, si les «requests» sur le projet initial permettent au propriétaire d’inclure facilement et rapidement la modification, l’existence des forks GitHub (c'est à dire un fork au niveau du code) permettent aussi de forker (ici employer dans le sens «traditionnel», c'est à dire au niveau projet) si le mainteneur ne fait pas son boulot !

GitHub est il seul ?

Plus maintenant, nous pouvons citer un concurrent libre (vous pouvez héberger votre propre site) qui s'appelle Gitorious. Il offre des fonctionnalités similaires, notamment dans l'aspect collaboratif (visitez par exemple la page du projet Git).

Dans le monde non Git, il existe d'autres plateformes, notamment Launchpad qui aurait pu connaître le succès de GitHub. Lancé en 2004, il dispose de nombreuses fonctionnalités de gestion de projet comme Answers pour le support de la gestion de la connaissance, Blueprints pour la spécification ou Translations pour la traduction ou les PPA pour l'hébergement de paquets Ubuntu. C'est la plateforme collaborative du projet Ubuntu, qui fédère des milliers d'utilisateurs. J'ai utilisé Launchpad très tôt (les projets Python étant les premiers utilisateurs de cette plateforme) et il avait un potentiel énorme. Hélas, la volonté de pousser l'outil maison à tout prix (en l'occurence Bazaar) a ôté toute chance à la plateforme de connaître un réel succès, Bazaar (que l'on écrit souvent «bzr») n'ayant pas décollé par rapport à Git et Mercurial. Dommage.

Autre concurrent, Bitbucket. Ce dernier est proche de GitHub mais utilise Mercurial (que l'on écrit souvent «hg») en offrant hébergement gratuit comme payant. Comme pour Launchpad, c'est aussi le manque de popularité de Hg par rapport à Git qui fait (pour l'instant) de BitBucket un outsider et non un concurrent direct. Mais le rachat par Attlassian (connu des Javaistes pour développer JIRA et Confluence) en septembre 2010 peut changer la donne.

Google Code est aussi une plateforme de qualité (avec Wiki, bugtracker, site web, visualiseur de source). Initialement limité à Subversion, il est maintenant possible d'utiliser Hg. Mais Google code n'offre aucune fonctionnalité sociale, et l'intégration de Hg est peut être un peu tardive (avril 2009).

Sourceforge est encore dans la course, grâce à une refonte complète du site. Le côté intéressant est que vous pouvez utiliser l'outil de gestion de source que vous voulez (cvs, svn, git, hg, bzr) avec accès à une base MySQL. Néanmoins, la refonte peine à cacher l'aspect vieillissant, il suffit pour cela de visiter un projet et de faire une comparaison avec le design clair d'un Bitbucket ou GitHub.

Enfin, vous avez de nombreuses «forges logicielles», ces sites vous permettant d'héberger vos projets libres. On peut citer Alioth, BerliOS, Tigris, Assembla, KForge, GNU Savanah... Mais encore une fois, elles font bien pâles figures face aux sites «sociaux», et n'offrent généralement pas d'hébergement payant (permettant leur développement en payant des développeurs).

Néanmoins, il est vital pour l'écosystème du Logiciel Libre (et le marché de l'hébergement de code) d'avoir des concurrents sérieux. J'espère donc que Bitbucket ou Launchpad évolueront rapidement dans le bon sens, obligeant GitHub à travailler sans relâche pour rester en tête.