Carte de GitHub
(github.com/anvaka)- Map of GitHub est une carte qui représente plus de 690 000 projets GitHub sous forme de points ; plus deux projets ont de stargazers en commun, plus ils sont placés proches l’un de l’autre
- Pour créer la carte, le jeu de données public des événements d’activité GitHub dans Google BigQuery a été utilisé, avec environ 500 millions de données d’étoiles issues des événements de février 2011 à mai 2025
- Les relations entre dépôts ont été calculées avec la similarité de Jaccard exacte ; un ordinateur domestique doté de 24 Go de RAM ne suffisait pas, et le traitement a pris plusieurs heures sur une instance AWS EC2 avec 512 Go de RAM
- Après avoir testé plusieurs algorithmes pour le clustering, Leiden clustering a été retenu ; au final, environ 690 000 projets ont été répartis en plus de 1 500 clusters
- Le rendu a été implémenté en combinant un outil de mise en page maison avec maplibre, GeoJSON et tippecanoe ; une grande partie des étiquettes de pays a été générée avec l’aide de ChatGPT
Présentation du projet
- Map of GitHub est une carte qui visualise plus de 690 000 projets GitHub
- Chaque point représente un projet
- Les projets ayant de nombreux utilisateurs les ayant étoilés en commun sont placés plus près les uns des autres sur la carte
Versions publiques
- Version actuelle, 10 mai 2025 : 690 000 projets, 1 500 clusters
- Version initiale, 8 mai 2023 : 400 000 projets, 1 000 clusters
Collecte des données et calcul de similarité
- La première étape consiste à récupérer quels utilisateurs ont attribué une étoile à quels dépôts
- Le jeu de données public des événements d’activité GitHub dans Google BigQuery a été utilisé
- La période couverte va de février 2011 à mai 2025
- Ce processus a permis d’obtenir environ 500 millions d’étoiles
- La deuxième étape consiste à calculer la similarité de Jaccard exacte entre chaque dépôt
- La charge de calcul était trop importante pour un ordinateur domestique avec 24 Go de RAM
- Sur une instance AWS EC2 dotée de 512 Go de RAM, le traitement s’est terminé en quelques heures
- D’autres méthodes de similarité ont aussi été testées, mais Jaccard a produit les résultats les plus fiables
Clustering et disposition de la carte
- La troisième étape a consisté à essayer plusieurs algorithmes de clustering pour regrouper les dépôts
- Au final, Leiden clustering a été préféré, et environ 690 000 projets ont été divisés en plus de 1 500 clusters
- La quatrième étape utilise l’outil maison ngraph.forcelayout pour positionner les nœuds à l’intérieur des clusters
- Une configuration distincte est utilisée pour la disposition globale de l’ensemble des clusters
Méthode de rendu
- La cinquième étape est le rendu de la carte
- Contrairement aux projets précédents, maplibre est utilisé afin de ne pas réinventer la roue
- Les données sont converties au format GeoJSON
- tippecanoe est utilisé pour générer les tuiles
- L’expérience de navigation sur la carte est ensuite construite
Génération des étiquettes de pays
- De nombreuses étiquettes de pays affichées sur la carte ont été générées avec l’aide de ChatGPT
- Si vous repérez une étiquette incorrecte, vous pouvez la corriger par clic droit et envoyer une pull request
- Le prompt système pour générer les étiquettes considère les groupes de dépôts GitHub comme des « pays » appartenant à une communauté de programmation donnée, et demande de créer des noms uniques et faciles à retenir
- Le nom doit être concis, en 1 à 3 mots
- Il doit saisir le thème, la technologie ou l’objectif commun du groupe de dépôts
- Les expressions génériques comme « JSWorld », « UI », « Web », « Forge », « Archipelago », « Hub », « Republic » ou « Nexus » doivent être évitées
- Il ne faut pas simplement combiner des noms de dépôts similaires
- Le nom doit se distinguer des autres noms de pays au point d’être immédiatement identifiable sur la carte
- L’entrée utilisateur contient
repoListetrepoNamesOnly, et demande d’analyser les thèmes et technologies précis de ces dépôts pour produire un nom - Si le LLM renvoie un nom trop similaire à un nom précédent, une nouvelle tentative est lancée et la temperature est augmentée afin d’obtenir un résultat plus créatif
Recherche et design
- Le champ de recherche est implémenté en indexant un simple dump de tous les dépôts par première lettre ou par auteur
- Lorsque l’on saisit
adans le champ de recherche, les dépôts commençant parasont recherchés et affichés côté client au moyen d’un fuzzy matcher - La représentation actuelle des données est satisfaisante, mais le style visuel de la carte n’a pas encore trouvé son design idéal
- Les personnes ayant de l’expérience en design cartographique ou des idées visuelles sont invitées à les partager
Licence
- Le dépôt est publié sous licence MIT
- Si les données sont utilisées dans d’autres travaux, il est demandé d’envisager une attribution à ce projet
1 commentaires
Avis sur Hacker News
Pour une raison ou une autre, torvalds/linux se trouve à Fronterra, à côté de projets JS, de listes awesome-X et de checklists frontend.
Soit les hackers du noyau se sont soudain pris d’amour pour le frontend, soit, plus probablement, les personnes qui écrivent du code et celles qui étoilent des projets GitHub ne se recoupent pas tant que ça.
Ils ne paraissent pas similaires parce qu’ils ont un lien sémantique, mais simplement parce qu’ils sont tous les deux populaires.
J’ai rencontré le même problème avec la carte de reddit : https://anvaka.github.io/map-of-reddit/ — les subreddits populaires finissent tous par être « similaires » entre eux.
Cela dit, ça marche toujours bien pour les projets plus petits et moins connus :D
Mais vu les ressources nécessaires pour télécharger chaque fichier et calculer les embeddings, ce serait sans doute difficilement réaliste.
https://xkcd.com/1138/
Le vrai lien : https://anvaka.github.io/map-of-github/
J’ai ri en voyant que la zone Among Us s’appelait Sussex.
Je suis surpris que Rustland soit si petit. Ce n’est guère plus qu’une province dans Clouderra.
C’est aussi intéressant que Bevy et Veloren soient tous les deux dans Rustland. Les étoiles viennent probablement davantage de la communauté Rust que de la communauté du développement de jeux.
Cela se tient si l’on considère que l’écosystème Rust est encore relativement petit et qu’il semble y avoir beaucoup de gens qui font « X en Rust ».
On surestime tous sans doute la taille de notre propre bulle.
Donc « X but in Rust » peut très bien se retrouver du côté de « X » plutôt que de « RustLand ».
C’est très amusant de pouvoir retrouver mon projet mapbox-gl-utils ici.
https://anvaka.github.io/map-of-github/#12/24.78947/18.85186
Sans fonction de recherche, essayer de retrouver un projet précis uniquement sur la carte devient un mini-jeu amusant :-)
En tant que fan de Julia, je suis surpris que julialang/julia ait si peu de connexions.
C’est certes un langage de niche, mais son apparence aussi isolée sur cette carte ne semble pas totalement éloignée de l’expérience des utilisateurs ou des développeurs.
Le fait que julialang/julia lui-même soit près de tensorflow et opencv, tandis que les vrais packages Julia soient regroupés ailleurs, semble montrer la différence entre les « utilisateurs espérés » et les « utilisateurs réels ».
Beaucoup des personnes qui ont étoilé le projet Julia lui-même étaient des utilisateurs de Python numérique à la recherche d’un nouveau Python, mais la plupart sont restés sur Python, et leurs autres étoiles se trouvent donc aussi du côté de Python numérique.
À l’inverse, les personnes qui ont étoilé les packages JuliaLand sont de vrais utilisateurs de Julia, ce qui les place de façon assez plausible près de Moleculandia, AstroSpace et Quantumia.
C’est une approche très propre et créative, mais je suis honnêtement partagé sur le fait que la métaphore pays/carte soit la meilleure.
Dans beaucoup de cas, les noms seuls ne sont pas clairs, et il faut zoomer pour comprendre ce qu’ils représentent.
Une approche avec du clustering hiérarchique, des libellés générés par LLM plus descriptifs et fidèles, puis des lignes montrant la connectivité moyenne entre les clusters de haut niveau aurait peut-être été plus intéressante.
Pour avoir commencé à créer ce genre de schémas dans les années 90 et en avoir presque immédiatement appris les limites, j’apprécie que celui-ci n’en fasse pas trop. Ce n’est pas un article scientifique, juste une visualisation.
J’aime les graphiques dont les axes ont du sens. Les lignes, les formes, les boîtes/groupes, les distances, X contre Y, les couleurs, l’épaisseur, la texture, l’arrière-plan, le premier plan, ce genre de choses.
La simplicité aussi, c’est bien. Trop souvent, on trace des lignes uniquement pour faire joli, sans qu’elles signifient quoi que ce soit ; ici, c’est juste une image avec quelques groupes et une personnalité. C’est bien, non ?
Bien sûr, j’aime toujours les lignes, mais elles ne sont pas nécessaires partout, tout le temps.
Il arrive souvent qu’il y ait plusieurs façons cohérentes de regrouper les données, si bien qu’aucun clustering final n’est parfait.
Hmm… peut-être qu’un clustering quantique pourrait faire un projet amusant.
C’est un peu flou maintenant, mais je me souviens avoir essayé l’algorithme hdbscan, c’est-à-dire un clustering hiérarchique. Impossible de le faire tenir en mémoire pour un graphe à l’échelle de GitHub.
Au final, j’ai utilisé quelque chose de proche du clustering hiérarchique, un mélange de louvain/leiden/une méthode maison, et ce qu’on voit sur la carte finale en est le résultat.
Quitlessia et NeoQuitlessia… ces noms sont diaboliques.
Doom Emacs se trouve dans NeoQuitlessia et pas dans Emacsia, et étonnamment ça se tient :)
Nous ne quitterons pas.
Je me demande comment les connexions entre dépôts sont déterminées.
J’ai vérifié quelques-uns de mes dépôts, et pour certaines connexions je ne vois aucune référence dans un sens ni dans l’autre.
En gros, comme d’autres l’avaient deviné, les lignes représentent les scores de similarité les plus élevés sur la base des « personnes qui ont étoilé », et toute la carte est également formée selon ce critère.
Cela peut prêter à confusion, mais les lignes n’apparaissent que lorsqu’on clique sur un pays donné.
J’imagine qu’il existe un seuil codé en dur pour décider de créer ou non une arête. Par exemple, si la similarité de Jaccard entre A et B est supérieure à 0,2, on crée une arête.