Difficile pour un développeur, en 2013, de ne pas savoir se servir de GitHub. Bien que jeune, la plate-forme d’hébergement de projets logiciels est probablement aujourd’hui le plus gros dépôt collaboratif du monde avec plus de trois millions d’utilisateurs et six millions de dépôts.
Ce qui avait commencé, en octobre 2007, comme un projet personnel, sans intention commerciale, est devenu aujourd’hui un pilier central de la collaboration logicielle et permet, chaque jour, à des milliers de développeurs de travailler ensemble à travers le monde.
Si vous ou votre organisation ne partagez pas de code sur GitHub, vous devriez. Et bientôt, les entreprises de production de logiciels ne seront plus seules…
GitHub, de l’outil pour développeurs à la collaboration productive
GitHub est né de la volonté commune de Tom Preston-Werner et Chris Wanstrath de résoudre la problématique de la collaboration décentralisée dans le cadre du développement. Un premier pas technique avait déjà été réalisé avec Git, un système de gestion de code source développé par Linus Torvalds, le créateur de Linux. Git est un très bon outil de collaboration décentralisée, mais il ne suffit pas à couvrir le périmètre fonctionnel de la collaboration sur un projet. Il manquait à Git une plate-forme, GitHub est venu combler ce manque.
Il est désormais possible, pour n’importe quel développeur de créer un dépôt, d’y héberger un projet, de le documenter sous la forme d’un site Web GitHub.io et de le proposer à la Communauté. Il peut lui-même s’approprier d’autres projets, y corriger des erreurs ou y apporter son savoir-faire puis proposer ses corrections au créateur du projet d’origine… ou non. GitHub permet et facilite ces interactions, tout en proposant les fonctionnalités d’un réseau social, comme la possibilité de personnaliser son profil ou celle de s’inscrire à l’activité d’un autre utilisateur.
Reposant sur sa simplicité d’usage, tout en offrant une qualité de service et un contrôle des données de premier ordre, la plate-forme a connu un succès fulgurant. Arrivé au million d’utilisateurs en trois ans environ, GitHub en héberge désormais plus de trois millions et met moins de cinq mois à acquérir chaque million d’utilisateurs supplémentaire.
Comment l’expliquer ? La force de GitHub a été de proposer une plate-forme centralisée pour ces tâches qui, par définition, se produisent de pair à pair (en se basant sur Git) tout en offrant une interface sympathique (là où SourceForge est un peu poussiéreux) et des fonctionnalités qui complétaient l’offre classique (comme Gist, ou GitHub.io). Et tout cela en présentant des conditions d’utilisation très claires qui laissent la totale propriété du contenu produit à leurs auteurs, comme l’indiquent les Terms Of Service :
We claim no intellectual property rights over the material you provide to the Service. Your profile and materials uploaded remain yours. However, by setting your pages to be viewed publicly, you agree to allow others to view your Content. By setting your repositories to be viewed publicly, you agree to allow others to view and fork your repositories.
A cela s’ajoute qu’il est plus motivant de travailler à plusieurs que seul : les dépôts des comptes gratuits étant publics, ils sont autant d’invitation à venir lire la production de camarades ou de collègues et leur proposer des évolutions. Autre conséquence : une grande majorité des statistiques des personnes, des organismes ou des entreprises présentes sur GitHub sont publiques, permettant à GitHub de devenir un vrai CV d’aptitude auprès des communautés concernées.
Mais si GitHub remporte autant de succès, c’est aussi qu’il intervient au bon moment : ce second âge d’or de l’Open Source. Ces dernières années ont vu à la fois naître des projets de qualité qui sont toujours en cours de développement (Android, Hadoop, MongoDb, …) mais aussi une grande évolution des mentalités face à l’Open Source, notamment en entreprise où l’on remarque une disparition progressive, sinon totale, de l’opposition des plus traditionnels. Certains employeurs encouragent même leurs salariés à contribuer sur des projets, quand ce ne sont pas des villes (comme Chicago), de grandes institutions du savoir comme la NASA ou même des gouvernements (comme le Royaume-Uni ou les Etats-Unis).
L’inverse se produit également : des entreprises, comme OVH, refusent que leurs salariés participent à des projets sur GitHub. Pourquoi ? Tout simplement parce qu’elles reconnaissent la capacité de GitHub à valoriser un profil et craignent la fuite des cerveaux. Une opposition en forme de succès pour la plate-forme.
Un business-model éprouvé
Pourtant, il est évident que GitHub ne s’adresse pas qu’aux particuliers. Ces derniers représentent la grande majorité des comptes et peuvent utiliser les fonctionnalités collaboratives de la plate-forme gratuitement s’ils le souhaitent. Mais s’ils le préfèrent, ils peuvent souscrire un abonnement leur permettant de développer à l’abri, sur des dépôts privés, des portions de code propriétaire par exemple. Mais le cœur du Business Model de GitHub repose sur les entreprises.
Celles qui souhaitent gérer de multiples dépôts, avoir un seul tableau de bord ou ajouter des collaborateurs en lecture souscrivent un forfait “Organization”. Mais ce forfait ne satisfera pas les plus grands acteurs pour qui il est impossible de partager leur code sur une plate-forme externe pour des problèmes de gouvernance ou de sécurité… Ces entreprises souscrivent donc un abonnement leur permettant d’héberger en interne une instance de la plate-forme, à la manière de Google Search Appliance pour la recherche, contre ce qui pourrait ressembler à plusieurs millions de dollars par an (les chiffres ne sont pas publics). Microsoft, VMWare, Walmart ont déjà été séduits.
GitHub, ou l’Open Source appliqué au monde
La problématique de la production distribuée d’un contenu au sein d’un projet n’est pas liée purement au monde du développement logiciel. Dans d’autres domaines, la production puis la mise en commun de contenus écrits à plusieurs mains relèvent du défi, car la culture et l’outillage Open Source n’existe pas. Et si une plate-forme comme GitHub pouvait solutionner ce problème ?
Certains, comme Loren, ont déjà essayé d’imaginer l’utilisation de GitHub pour l’écriture :
- L’auteur principal créé la structure basique d’un document et quelques éléments de base (branche master) ;
- Chaque collaborateur voulant contribuer peut démarrer en un clic la contribution sans se préoccuper de gêner les autres contributeurs (en réalisant un fork) ;
- Une fois cette contribution terminée, son auteur propose à l’auteur original de valider sa contribution (via un pull request) ;
- Si la contribution est validée, elle peut rejoindre le document. Sinon, les raisons du refus sont notifiées à son auteur, de manière à ce qu’il puisse réaliser les corrections nécessaires avant une nouvelle contribution.
Ce processus, classique, est entièrement supporté par la plate-forme, mais elle n’est pas forcément adaptée en termes de design. L’idée a cependant servi de support à la création de Penflip… et à d’autres initiatives, plus orientées vers le design visuel ou industriel, la musique. C’est par exemple le cas de Splice, qui devrait ouvrir ses portes prochainement. Y retrouvera-t-on les grands de l’Electro française (et mondiale) ?
Quelques liens, pour en savoir plus
- http://readwrite.com/2013/09/30/understanding-github-a-journey-for-beginners-part-1
- http://www.wired.com/opinion/2013/03/github/
- http://radar.oreilly.com/2013/03/github-government-bureaucat-open-source.html
- http://bits.blogs.nytimes.com/2012/12/28/github-has-big-dreams-for-open-source-software-and-more/
- http://thenextweb.com/insider/2013/04/11/code-sharing-site-github-turns-five-and-hits-3-5-million-users-6-million-repositories/
- http://www.inc.com/magazine/201303/will-bourne/2-reasons-to-keep-an-eye-on-github_pagen_2.html
Jean-René Lither
15 novembre 2013
Merci pour cette reaction a l’actualite de la programmation.
Je lit avec assiduite et passion votre blog, qui me tient au courant des dernieres nouveautes du monde des developpeurs. On sent que vous etes des gens pointus.
Continuez s’il vous plais a nous donnez du savoir de derniere fraicheur, ca fait du bien !
Boris Schapira
15 novembre 2013
Merci pour ce commentaire qui fait chaud au coeur !
Nous allons faire de notre mieux pour continuer d’être à la hauteur de vos attentes.
Rudy Rigot
15 novembre 2013
100% d’accord avec le fait que le futur de la gestion de contenus collaborative ne peut se faire qu’avec un modèle de contribution qui se rapproche du workflow de Git.
(Révélation secrète : on peut aujourd’hui « brancher », « merger », « taguer », et « faire un diff » dans prismic.io, et on travaille sur une feature qui ressemblera au « pull request » quand un contributeur souhaitera ajouter une version de document sur une future release de contenus. Stay tuned, comme ils disent !)
Par contre, plus je discute avec des contributeurs de contenus, plus il me semble évident qu’on ne pourra pas utiliser les mêmes mots-clés très techniques que ceux de Git. La bonne nouvelle, c’est que les mots-clés de Git sont techniques parce qu’ils sont agnostiques de quel type de fichier au juste est en train d’être versionné. À partir du moment où tu sais que tu es en train de manipuler du contenu, il est possible de trouver des dénominations plus concrètes, plus abordables pour les contributeurs de contenu.
Il y a aussi une valeur forte à garder venant du modèle Git : aujourd’hui les CMS représentent des frustrations fortes pour le contributeur au sujet de « ce qu’il a le droit de faire, ce qu’il n’a pas le droit de faire ». En laissant la liberté à tous les contributeurs de modifier tout ce qu’ils veulent, mais en positionnant le contrôle du contenu plus haut, lors de la publication/planification du contenu (en proposant des outils optimisés pour faire de la revue efficace de modifications), on supprime une énorme frustration du modèle CMS (pour le contributeur, mais aussi pour l’administrateur de contenus).
Super billet, qui donne du grain à moudre d’excellente qualité ! :)
En d’autres nouvelles, je vais faire un tour dans les locaux de GitHub la semaine prochaine, et il paraît que c’est énorme……. Je prendrai des photos !!! :)
Boris Schapira
15 novembre 2013
… photos que tu t’empresseras d’envoyer à tes anciens collègues, bien sûr ! Hâte de voir ça !
Complètement d’accord avec toi sur l’absolu nécessité d’utiliser un vocabulaire adapté, voire une interface adaptée si elle existe. C’est une des raisons pour lesquelles je tenais à citer Splice, donc les premières captures traduisent bien le mélange entre les spécificités du monde de la musique et celui de la gestion de contenu numérique.
Boris
6 février 2014
Pour ceux qui voudraient en savoir davantage sur les chiffres de l’univers GitHub : http://octoverse.github.com/