What is the truck factor of GitHub projects?

Single-man projects are very common.

Truck Factor designates the minimal number of developers that must leave (i.e., get hit by a truck or bus, or win in the lottery) before a project becomes unsustainable. Therefore, TF measures the dependency of a project on a small number of members.

Last year, we proposed an algorithm to estimate the truck factor of software projects, using data from version control systems. We used the algorithm to compute the truck factor of 133 popular GitHub systems. The algorithm was first published in the form of a preprint at PeerJ, which attracted a lot of interest (it has 8,600 downloads). We also published a paper at ICPC 2016.

Now, we implemented a web-based tool, called GitTrends, which estimates the truck factor for more than 3,000 popular GitHub projects.


For example, this chart shows the Truck Factor (TF) results for the 25 popular open source projects, as estimated by GitTrends

  1. FreeCodeCamp: 1
  2. Bootstrap: 3
  3. D3: 1
  4. React: 4
  5. AngularJS: 6
  6. Font-Awesome: 1
  7. oh-my-zsh: 65
  8. jquery: 4
  9. electron: 1
  10. tensorflow: 2
  11. docker: 13
  12. meteor: 5
  13. swift: 5
  14. vue: 1
  15. rails: 11
  16. atom: 4
  17. revelal.js: 1
  18. impress.js: 1
  19. nw.js: 3
  20. semantic-ui: 1
  21. node.js: 10
  22. three.js: 3
  23. moment: 1
  24. socket.io: 2
  25. express: 1

As we can see, 10 systems in this list are single-man projects (TF = 1).

GitTrends also provides historical data about TFs. For example, this chart shows the TF of several AngularJS releases. We can see the TF is increasing over time, from 1 in some of the initial releases to 6 in release 1.5.5.

Truck Factor of several AngularJS releases

Important notes:

  1. The results provided by GitTrends are an estimation, based on code authorship measures. As recommend to all software metrics, TF results should not be used without proper interpretation.
  2. Good software engineering practices certainly contribute to overcome truck factor episodes (documentation, tests, etc; see again our previous paper). However, as an automatic tool, GitTrends does not consider these practices to estimate TFs.
  3. In case the TF developers leave a project, this does not necessarily mean the project will be discontinued, but that its maintenance and evolution will be in trouble. For example, bugs might take more time to get fixed and new features might take more time to be implemented.
  4. GitTrends estimates TFs considering all the project’s code available on GitHub. This explains the high result achieved by oh-my-zsh (TF=65), which is a system whose codebase includes several plug-ins, themes, etc.

For more TF results, please look at the GitTrends site. Besides TF results, GitTrends also provides data about the popularity of GitHub systems.