source{d} has recently published a dataset with metadata on 462,000,000 commits: data.world. It allows you to build the contributions graph. For example, these are the neighbors around Armin Ronacher:

*Neighbors around Armin Ronacher, 2 generations - the repositories he contributed to and their contributors. Armin is in the center. 8k nodes, 11k edges. The graph was produced with Gephi.*

The fans on the above image are communities around some popular open source projects, e.g. rust-lang/rust on the bottom.

*Neighbors around Armin Ronacher, 3 generations. Armin is again somewhere in the center. 200k nodes, 300k edges.*

These are the neighbors around Rob Pike:

*Neighbors around Rob Pike, 3 generations, zoomed center region. Nodes are highlighted with the heatmap tool to reflect the distance from Rob. Hubs: upper-left: golang/go ^{*}, upper-right: onef9day/gowiki, lower-left: cmars/oo, lower-right: cmars/tools.*

*Schematic abstraction of the previous graph. Edge weights are the number of commits.*

Actually, Rob Pike has never contributed to cmars/oo and cmars/tools. The owner of those repos must have used `git filter-branch`

or something similar to forge the history. This is why it is so hard to distinguish the real contributions in Git world!

*ADJACENCY MATRIX*

The contributions graph is bipartite and is represented by an extremely sparse adjacency matrix:

*The square adjacency matrix of the contributions graph. C _{ij} is the number of commits done by developer i to repository j; C_{ij} = C_{ji}.*

I continue mining the October 2016 snapshot, at that time the matrix was about 23 million by 23 million and contained 48 million non-zero elements. Of course, these numbers are approximate - we depend on our identity matching here. The identity matching is the way to merge several email addresses into a single personality and it is not an easy task because we have to make assumptions. The public dataset has hashes instead of email addresses so it is impossible to perform the identity matching on that data. You can download the graph here. It is a pickled `scipy.sparse.csr_matrix`

, the following Python code loads it:

```
import pickle
with open("graph_blog_post.pickle", "rb") as fin:
graph, repos = pickle.load(fin)
ndevs = graph.shape[0] - len(repos)
print(repr(graph))
print("Number of developers:", ndevs)
print("Number of repositories:", len(repos))
inv_repos = {r: i + ndevs for i, r in enumerate(repos)}
name = "src-d/go-git"
print("Repository %s has %d contributors, %d commits" % (
name, len(graph[inv_repos[name]].indices), graph[inv_repos[name]].sum()
))
```

```
<23223056x23223056 sparse matrix of type '<class 'numpy.float32'>'
with 47866516 stored elements in Compressed Sparse Row format>
Number of developers: 6621684
Number of repositories: 16601372
Repository src-d/go-git has 14 contributors, 169 commits
```

We ship only the second part of the matrix index, the repository name → index mapping. Please note the following:

- We were unable to process some large repositories back in October. Particularly, about 20% of the most highly rated ones. That is, unfortunately, there is no data for
`git/git`

,`torvalds/linux`

,`rails/rails`

, etc. - Some secondary repositories were confused with the main ones. E.g. there is no
`golang/go`

but rather some random`4ad/go`

. That was a bug we’re now fixing. - Initially we had 18M repos, but filtered 1.5M duplicates not marked as forks; read this blog post how.

Let’s conduct two funny experiments with our graph:

## the handshake theory

The six handshakes theory, or Six degrees of separation, states that everybody in the world can reach out everybody else using the chain of sequentially familiar people of the size smaller than or equal to 6. Supposing that you know all the people who contributed to the same projects you contributed yourself, we can accept or reject this assumption on GitHub contributions graph.

The plan will be as follows.

- Find all the connected components of the graph.
- Pick the core component, or simply “the core”. Calculate the size of the representative sample of the pairs of nodes.
- Calculate the distances between sampled node pairs.
- Plot the histogram, draw the conclusion.

We need to determine the connected components because it is impossible to find a path between nodes lying in different components and every shortest path algorithm has to scan all the nodes before returning the negative result. We’ve got 23M dots, remember.

*CONNECTED COMPONENTS*

While our graph is directed, every edge has the corresponding backward edge of the same weight, so the weak connectivity automatically means strong connectivity. In other words, we do not need to apply complex algorithms designed to find the strongly connected components, but rather conduct the series of graph traversals. For example, the following code works:

```
def RFS(v_start):
visited = set()
pending = {v_start}
while pending:
v = pending.pop()
visited.add(v)
if len(visited) % 500000 == 0:
print(len(visited))
for i in range(graph.indptr[v], graph.indptr[v + 1]):
nv = graph.indices[i]
if nv not in visited:
pending.add(nv)
return visited
unvisited = set(range(graph.shape[0]))
components = []
while unvisited:
v = unvisited.pop()
c = RFS(v)
components.append(c)
if len(components) % 100000 == 0:
print(len(components))
unvisited -= c
print("Number of connected components:", len(components))
clens = list(sorted((len(c) for c in components), reverse=True))
print(clens[:10])
```

The traversal algorithm is neither depth-first nor breadth-first. It is random-first as Python’s `set`

is an unordered container. Random-first traversal is sufficient for our task of visiting every connected vertex once and is faster. It takes about 5 minutes to execute. The result is:

```
Number of connected components: 3430141
[10200912, 10229, 8456, 2917, 2910, 2614, 2612, 2604, 2576, 2139]
```

We’ve the clear core with 10M nodes! How many developers are in it?

```
c0 = components[0]
core_devs = [m for m in c0 if m < ndevs]
print(len(core_devs))
```

```
2153559
```

That is, the “contributional active” GitHub users are 2.2M or 33% or ⅓ of the whole users we analysed, here we analysed about 73% of all the users who made at least 1 commit, and the official number of users is reported to be 20M (including users without any commits). Thus the final ratio is ** 11%**.

*EPRESENTATIVE SAMPLE*

We need to determine how many distances between random nodes in the core must be evaluated to achieve a statistically significant distribution. Let’s find a rough estimate. The number of possible distance pairs between the core developers is

```
print("Number of possible pairs:", len(core_devs) * (len(core_devs) - 1) / 2)
```

```
Number of possible pairs: 2318907106461
```

Now we should use the special calculator to find out the size of the representative sample from 2.3 trillion. For example, checkmarket.com. We set the population size to 2318907106461, the margin of error to 1% and the confidence level to 95% and see roughly 10,000. Not bad! This is how to sample 10k random vertices:

```
samples = numpy.random.choice(core_devs, 10000 * 2, replace=False).reshape((10000, 2))
```

*DISTANCES CALCULATION*

There are many shortest path algorithms out there. I can recall the following three from scratch:

- Floyd–Warshall allows to calculate the distances from everybody to everybody but has a tiny drawback - it works in O(V3) time and eats O(V2) memory. We cannot afford ourselves to store 23M × 23M = 5e14 elements (2 PB) and wait several years.
- Good ol’ Dijkstra allows to find all the shortest distances from one fixed node to all the rest in O(|E| + |V|log|V|) time and O(|V|) space. It works but it is not efficient on our graph. The problem is with the “generational explosion”, each next node generation is exponentially larger than the previous one, so Dijkstra’s algorithm ends up with inspecting almost all the nodes every time.
- Bidirectional search spreads simultaneous waves from the both nodes and suits our task best since this algorithm is less sensitive to the “generational explosion”.

Here is the code I used. It leverages the `multiprocessing`

package to calculate many shortest paths in parallel.

```
def path_length(first, second):
visited_first_set = set()
visited_second_set = set()
visited_first_paths = {}
visited_second_paths = {}
pending_first = [(first, 0)]
pending_second = [(second, 0)]
pending_first_set = {first}
pending_second_set = {second}
pmax = graph.shape[0]
path = pmax
# Breadth-first search single step
def step(visited_set, visited_paths, pending, pending_set):
v, p = pending.pop(0)
pending_set.remove(v)
visited_set.add(v)
visited_paths[v] = p
for i in range(graph.indptr[v], graph.indptr[v + 1]):
nv = graph.indices[i]
if nv not in visited_set and nv not in pending_set:
pending.append((nv, p + 1))
pending_set.add(nv)
while (path == pmax) and (pending_first or pending_second):
if pending_first:
step(visited_first_set, visited_first_paths, pending_first, pending_first_set)
if pending_second:
step(visited_second_set, visited_second_paths, pending_second, pending_second_set)
isect = visited_first_set.intersection(visited_second_set)
for v in isect:
p = visited_first_paths[v] + visited_second_paths[v]
path = min(path, p)
return path / 2
from multiprocessing import Pool
with Pool() as p:
paths = p.starmap(path_length, samples)
```

The script took less than 10 minutes to finish on our 32-core machine with 256 gigs of RAM. Each process takes less than 4GB of RAM which means 32 processes need less than 128GB.

We divide each path by 2 because the nodes corresponding to repositories should not be taken into account in the shortest path’s size calculation.

*THE HISTOGRAM*

85% of the core is less than or equal to 6 handshakes from each other. The average is 4.9, the maximum is 18. The average is close to what Facebook had in 2011. ∎

## github pagerank

As soon as we have the contributions graph, we want to find out whose GitHub is bigger. The natural way of doing this is to calculate some centrality measure. We decided to study eigenvector centralities which make nodes important if they are referenced by other important nodes.

*Armin Ronacher’s contributions, simplified PageRank version.*

wi depend on the impact to the project or to the ratio of the developer’s efforts. If our adjacency matrix contained strictly positive elements (everybody is connected to everybody) then by Perron–Frobenius theorem. x is the eigenvector of this matrix which corresponds to the greatest eigenvalue. Moreover, if the matrix is stochastic, that is, the sum of values in every column equals to 1,λ=1. The greatest eigenvalue and the corresponding eigenvector can be found by various efficient methods such as power iteration orArnoldi iteration.

Unfortunately, this is not applicable to our case: we’ve got a sparse matrix with a lot of zeros. Practically speaking, the greatest eigenvalue corresponds to an eigenvector with negative elements. We need to do something. Luckily, we are not the only ones who hit this problem. So did Larry and Sergey back in 1998. They studied the similar adjacency matrix of WWW pages. Each element Cij is 1 if page i links to page j and 0 otherwise. Larry and Sergey found the nice trick to make the adjacency matrix well-conditioned and suitable for * iteration methods which they called PageRank.

There is a good explanation of PageRank in Stanford’s CS246. I am not going to repeat it but rather briefly describe how the trick applies to our centrality problem using the terms from CS246.

*NORMALIZATION*

The following code performs the L1 normalization.

```
norms = 1 / numpy.asarray(graph.sum(axis=1)).ravel()
from scipy.sparse import diags
graph_normed = H = graph.dot(diags(norms, format="csc"))
```

Here is what happens:

`scipy.sparse`

API makes the diagonal matrix multiplication the only way to normalize the columns.

*THE GOOGLE MATRIX*

We are not going to ever calculate it explicitly because that would involve storing N × N elements! Instead, we will create a custom power iteration algorithm.

*POWER ITERATION*

The idea of the power iteration method is dead simple: if we want to find the vector x such that G⋅x=x then we repeat the same matrix multiplication until the convergence:

Provided that the matrix is well-conditioned, the convergence is guaranteed. Here is the code which calculates x.

```
def page_rank(m, beta=0.85, niter=80):
N = m.shape[0]
x = numpy.ones(N, dtype=numpy.float32) / N
for i in range(niter):
x_next = m.dot(x) * beta
x_next += (1 - beta) / N # ***
xdiff = numpy.linalg.norm(x - x_next, ord=1)
x = x_next
print("iter #%d: %f" % (i + 1, xdiff))
if i % 10 == 0:
print(x)
return x
page_rank(graph_normed)
```

`# ***`

every edge has the opposite one, so there are no “dead ends”. Otherwise, we would have to replace `beta`

with `x_next.sum()`

.

`page_rank()`

executes fast and the result is returned within a minute.

*WHO IS THE MOST IMPORTANT ON GITHUB?*

Ryan Baumann aka ryanfb! He is eventually a good example how to study how GitHub’s cache works (spoiler: it invalidates after some time).

*github.com/ryanfb takes several seconds to be generated.*

*Ryan knows what it means to be productive.*

I am joking, of course. Although he is on the top, he is actually the living illustration of the weaknesses PageRank algorithm has. There used to be days when Ryan created 1,000 repositories and of course he is not a super human - they were automatically generated. Yet he got *many* incoming links and PageRank rated him the highest.

The essential move would be to ignore repositories with a single contributor, and that definitely helps, though other fun effects still reflect the light. After all, only the ratio of PageRank-s makes sense. For example, after the mono repository filtering, Armin Ronacher has 8.0e-6, our CTO Maximo Cuadros has 2.6e-6 and I have 1.6e-6.

*WHAT IS THE MOST IMPORTANT ON GITHUB?*

Here is the descending top 200:

- bmorganatlas2/firstrepo
- nguyendtu/patchwork
- bmorganatlas/fusiontest5
- coeligena/homebrew-customized-copy
- KenStanley/reflections
- athurg/linux_kernel
- enkidevs/commit
- gentoo/wikiclone
- karmi/wikipedia_metal_umlaut
- Homebrew/homebrew-core
- renoirb/test
- SopraConsulting/CocoapodsSpecs
- openSUSE/salt
- caskroom/homebrew-cask
- borisyankov/DefinitelyTyped
- neuros/linux-davinci-2.6
- openstack/openstack
- TheOdinProject/curriculum
- NixOS/nixpkgs-channels
- levaidaniel/sbo
- RobertCNelson/device-tree-rebasing
- markphip/testing
- mutoso-mirrors/linux-historical
- Xilinx/u-boot-xlnx
- laijs/linux-kernel-ancient-history
- wikimedia/mediawiki-extensions
- Ningxiaobao/learngit
- FFmpeg/FFmpeg
- rust-lang/rust
- xwstrom/ffmpeg-3.0.2
- tieto/pidgin
- mesa3d/mesa
- drewgreenwell/playscript-mono
- ThomasGagne/sage-rijndael-gf
- chapuni/llvm-project-submodule
- lwhsu/freebsd-doc_old
- palmzeed/git
- yasee/cocos2d-x-custom
- illumos/illumos-gate
- wbond/package_control_channel
- WeichenXu123/wchen-spark
- khavnu/VLCLIB
- OpenDMM/linux
- larryhastings/gilectomy
- KDE/kdelibs
- EFForg/https-everywhere
- PrestaShop/PrestaShop
- John-NY/overo-oe
- webapproot/metasploit
- yiichina/yii2
- zmatsh/Docker
- jcenteno1973/sicafam
- Digital-Peak-Incubator/tpl_tauristar
- shibaniahegde/OpenStack
- aabudari/nova
- futuresimple/ansible-project
- instructure/canvas-lms
- Shinogasa/django
- codecombat/codecombat
- wireshark/wireshark
- dmgerman/git-test-decl
- koding/global.hackathon
- zurb/foundation
- JCBarahona/edX
- paladox/testmw
- woothemes/woocommerce
- ohmnam/spreee
- LCTT/TranslateProject
- patchew-project/qemu
- 0xbzho/asciinema.org-2015-02
- tikiorg/sf.net-users
- gentoo/gentoo
- fanwenyi0529/qemu-fvm
- weissets/happy-navi-osmand
- KDE/kdepim
- 0xbzho/asciinema.org-2015-04
- duckduckgo/zeroclickinfo-goodies
- julian-gehring/julia
- woodsts/buildroot
- citation-style-language/styles
- aospSX/platform_kernel_msm7x30
- mjudsp/Tsallis
- NICHO1212/laravel
- voidlinux/void-packages
- skillcrush/skillcrush-104
- jruby/jruby
- rdunning0823/tophat
- ctekhub/atom-t
- Azure/azure-quickstart-templates
- linzhangru/ROS
- maurossi/llvm
- forcedotcom/aura
- buckett/sakai-gitflow
- Tower-KevinLi/Designers-Learn-Git
- silverstripe/silverstripe-framework
- PyAr/wiki
- tonydamage/opendaylight-wiki
- android-source/platform_frameworks_native
- lolli42/TYPO3.CMS-Catharsis
- Roll20/roll20-character-sheets
- disigma/android_native
- gpcorser/cis255
- facebook/hhvm
- CSMByWater/koha
- robfig/plovr
- gitclienttester/gitclienttest
- github-book/first-pr
- chusopr/kdepim-ktimetracker-akonadi
- pydata/pandas
- servo/servo
- michaKFromParis/sparkslab
- qtproject/qt-creator
- soulteary/Get-D2-2014-Ticket
- Kitware/VTK
- facebook/react-native
- aarontc/kde-workspace
- jredondo/diaspora-murachi
- Distrotech/evolution
- mono/monodevelop
- dolphin-emu/dolphin
- unrealengine47/UnrealEngine4
- openSUSE/systemd
- alainamedeus/percona-server
- allyssonsantos/be-mean-modulo-mongodb
- alpinelinux/aports
- Mittineague/discourse-hacked
- jeremygurr/dcssca
- mozillazg/pypy
- ngoquang2708/android_vendor_sprd_open-source
- dart-lang/sdk
- Rockbox-Chinese-Community/Rockbox-RCC
- sudhamisha/vmw-kube
- matplotlib/matplotlib
- 4ad/go
- intel/theano
- LucHermitte/ITK
- kontulai/fdsaember
- jonlabroad/OpenHab-1.8.3-InsteonRestApi
- sriram1991/anjularJS_usefull
- Azure/azure-powershell
- adambard/learnxinyminutes-docs
- erikbuck/CS2350
- TheThingsNetwork/wiki
- cbeasley92/hack-summit-hackathon
- 2947721120/adamant-waffle
- hashicorp/terraform
- librenms/librenms
- Lyude/gtk-
- RR1007/Jenkins2
- Kitware/ParaView
- tgm4883/lr-rpi2
- Kasual666/WebGl
- jlouiss/freeCodeCamp
- danoli3/openFrameworksBFG2
- mozilla/spidernode
- ansible/ansible-modules-core
- scardinius/civicrm-core-api-mailing
- akka/akka
- mozilla/releases-comm-central
- stewartsmith/bzr
- KrauseFx/fastlane
- lpathy/hhvm-armjit
- krt16s/fdroiddata
- mongodb/mongo
- Yiutto/D3
- rg3/youtube-dl
- KDE/amarok
- xiaobing007/tachyon
- HydAu/Camel
- almania69/Gimp
- TEAMMATES/repo
- piwik/piwik
- pfsense/pfsense
- nadimtuhin/platform4
- highfidelity/hifi
- DarkstarProject/darkstar
- nishithshah2211/libvirt
- chscodecamp/github
- naraa/mangos
- mangosR2/mangos3
- mtahmed/poky-clang
- JuliaLang/METADATA.jl
- idano/home
- alfathony/codeigniter-restclient
- duckduckgo/zeroclickinfo-spice
- google/closure-compiler
- karthikjaps/elasticsearch
- dwinurhadia/openstack-doc
- sciell/ArduPilot
- 0xbzho/asciinema.org-2015-01
- wxWidgets/wxWidgets
- frugalware/kde5
- ManageIQ/manageiq
- dyon/skcore
- tmcguire/qt-mobility
- KSP-CKAN/NetKAN
- ShaneDelmore/scala
- freeminer/freeminer
- bartekrychlicki/bisect-kata
- cakephp/docs

It’s a pity we were unable to process some important repos like `torvalds/linux`

back in October, as I noted in the beginning, so they are absent. bmorganatlas2/firstrepo got to the top due to the failure of the identity matching: we’ve got the clique which is PageRank’s Achilles’ heel. This is not much of our fault: the guy created 30,000 commits, each under a different, obviously fake, author. How were we supposed to realize it without using GitHub API? The same failure happened with bmorganatlas/fusiontest5 (besides, it has 10,000+ branches!). Other repositories seem to be legit and typically have thousands of contributors, hence high PageRank. We are currently building out a large data pipeline that will increase the quality of our data and expand it beyond GitHub to almost all git repositories on the web.

## summary

This post studies the contributions graph which source{d} collected from GitHub repositories. The October 2016 dataset is open on data.world and can be used to build it, however, it can be downloaded fully baked from our Google Drive. We’ve had fun with proving the theory of 6 handshakes between GitHub core developers and measuring the community members’ importance by applying PageRank algorithm.

## update

This is what you get if you visualize the Google matrix with LargeVis:

I used `hexbin`

from matplotlib:

```
hexbin(graph[:, 0], graph[:, 1],
gridsize=2048, bins="log", cmap="inferno")
```