The Truck Factor Revealed
Thursday, 16 July 2015

Don't take this too seriously, but if 90 programmers working on the Linux kernel were to be hit by a truck then the project, and hence Linux, would be toast. If a truck score of 90 seems good what about other projects?


You have the idea now.

The Truck Factor of a project is, semi-humorously, defined as the number of programmers that would have to be hit by a truck to incapacitate the project. In a preliminary study Guilherme Avelino, Marco Tulio Valente and Andre Hora of the Department of Computer Science, UFMG, Brazil looked at GitHub projects. What would research into software and programming be without GitHub?

Each file in a project was accessed to work out its degree or authorship DOA by each developer. DOA involves a number of factors, but by far the most important is who created the file in the first place. To compute the Truck Factor a greedy heuristic repeatedly removed the author with the claim to have authored most files until more than 50% of the files were orphans - i.e. without an author. Thus a project is considered to be in real difficulties if more than 50% of its code no longer has an author. 

The results indicated that most projects had a small Truck Factor, which is bad. Around 46% had a Truck Factor or 1 and 28% had a Truck Factor of 2. The good news is that Linux had one of the highest Truck Factors of 90, beaten only by HomeBrew (a package manager for OSX) which had a Truck Factor of 159.

You can read the paper to find out all of the Truck Factors, but some that stand out immediately when you just scan the list are:

clojure/clojure, gruntjs/grunt, sass/sass,

with a Truck Factor of 1

cucumber/cucumber, drupal/drupal, wordpress/wordpress, 

with a Truck Factor of 2.  

bitcoin/bitcoin, gradle/gradle,  ipython/ipython  jquery/jquery, meteor/meteor

with a Truck Factor of 3.

After 3 things seem a bit more safe, but GIT comes in at only 8, Rails at 7 and the Android platform frameworks base comes in at 12.

So does this really mean that there are dangerous open source projects that you should avoid at all cost? 

Consider the Truck Factor of proprietary software. When any company ends a software project it is as if the entire programming team had been hit by a truck! More to the point, with open source if the worse happens you can still study the code and attempt to get back on top of it with the remaining team. 

We can't know how resilient an open source project really is because the experiment would involve real trucks and real people and I don't think we would get it past any ethics committees. 


More Information


Related Articles

How Alive Is That Project? 

OSS Watch Openness Rating

Beautiful Open

Programming Tribes

Bribe Devs To Improve Open Source Software

Carbon Dating The Web       


To be informed about new articles on I Programmer, install the I Programmer Toolbar, subscribe to the RSS feed, follow us on, Twitter, FacebookGoogle+ or Linkedin,  or sign up for our weekly newsletter.



Udacity Launches New Blockchain Nanodegree

Udacity has revamped its BlockChain Developer Nanodegree program. It is a two-month program at Beginner level, although you'll need to be familiar with JavaScript and the new emphasis is how Blockchai [ ... ]

Initialize Your Spring Boot Projects From The CLI

For the lovers of the command line, Spring Initializer Go is a tool with which you can initialize your Spring Boot projects without using the mouse. Is that essential?

More News


C book



or email your comment to:

Last Updated ( Thursday, 16 July 2015 )