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?

lorry

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, 
mozilla/pdf.js

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. 

lorry

More Information

Truck-Factor

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.

 

Banner


Visual Basic Problems From Windows Update
16/08/2019

There's a problem for applications based on Visual Basic for all Windows machines that have installed the cumulative updates for August. The issue, raised by Microsoft, says that apps may stop respond [ ... ]



Refactoring to Kotlin Codelab
23/07/2019

Learn how to convert Java to Kotlin using Kotlin's idioms with Google Developers Codelabs. Refactoring to Kotlin, which is available in English, Brazilian and Chinese, provides a guided, hands-on codi [ ... ]


More News

 

appC

 



 

Comments




or email your comment to: comments@i-programmer.info

Last Updated ( Thursday, 16 July 2015 )