

What Is the Truck Factor of Popular GitHub Applications? - adamnemecek
http://mtov.github.io/Truck-Factor/?

======
NathanKP
The algorithm is inherently flawed because it is based purely on authorship of
files, and not the quality of the documentation, source code, source code
comments, etc.

It doesn't matter if a piece of software was written by only one person. If it
has great documentation then the original author can die (or less morbidly
just abandon it) and someone else can pick it up easily.

All the node.js modules by TJ Holowaychuk are a good example. They are
extremely well written and documented, allowing them to continue being worked
on by alternate maintainers even though he has moved away from the Node.js
ecosystem to Go.

~~~
5outh
Case in point: Express is now owned by strongloop and is still (no pun
intended) going strong.

------
hlieberman
This analysis seems to me to be deeply flawed. At only a glance, at least two
of the projects mentioned at TF=2 have entire companies that are dedicated to
them: ansible and elastisearch.

According to Crunchbase, Elastic.co has between 51 and 200 employees, and has
raised over $104MM in venture capital. According to Github, there are at least
27 employees of Ansible, Inc. that have commit access to github. Even if we
assume that many of these people are not "core developers", saying that the
"truck-factor" is /2/ is so far from accurate as to go from merely wrong to
straight-up deceitful.

~~~
hobarrera
> This analysis seems to me to be deeply flawed. At only a glance, at least
> two of the projects mentioned at TF=2 have entire companies that are
> dedicated to them: ansible and elastisearch.

Even if there's an entire company behind it, that doesn't mean that everybody
at that company is an expert in that software. Maybe just one or two devs had
a good understanding on how it works, and the rest work on different things,
document, or maybe just know it superficially.

~~~
hlieberman
It stretches credulity to believe a $100MM+ company only has two developers
who are an expert in the software -- especially when it's their most important
product.

------
kabouseng
Why do the author call it truck factor. Even the wikipedia link in the article
calls it bus factor.

~~~
forgottenpass
Interchangeable terms. One is more popular than another.

~~~
angersock
More popular insofar as _almost nobody ever calls it the truck factor_.

~~~
dj-wonk
I prefer to call it the "Car With Distracted Driver Factor".

------
emn13
Another smell: projects with small files will appear to have a low truck
factor; whereas those that group code into very large files (edited by
multiple people) will tend to have a very high truck factor.

Then theres the fact that irrespective of code quality, not all code bit-rots
equally. Some code needs frequent updates to stay with times; some needs minor
touches to track small api changes over the years, and some code is pretty
much set in stone - it's virtually never touched except for languages changes.

This algorithm isn't measuring the truck factor.

------
matthewbauer
This is definitely an interesting metric. It would be useful to look at this
when deciding on using a dependency in a project.

I suspect that the Homebrew project is a little skewed because recipes are
checked into the repository. Although these are technically source code, they
aren't really part of the core of what is necessary to understand the code
behind Homebrew's source.

~~~
lemevi
I'm pretty sure actual HomeBrew's bus-factor is 1, it's just 1 guy working on
core HomeBrew.

~~~
sz4kerto
And he can't invert a damn binary tree on a whiteboard.

~~~
dj-wonk
?

~~~
superplussed
[https://twitter.com/mxcl/status/608682016205344768](https://twitter.com/mxcl/status/608682016205344768)

------
Baghard
As a developer is it a good or a bad thing to have a high Truck Factor? There
seems to be a trade-off. Management and business wants low Truck Factors, but
talented developers do not want to be replaceable code monkeys. Do projects
with a low Truck Factor lose specialist knowledge?

Then I wonder when the Truck Factor applies and if you would always want to
lower it. For a few projects I worked on invoking this Truck Factor irked me.
A low Truck Factor is insulting to your skills (for you ten others), but a
high Truck Factor can be too. Who likes to hear that management is already
planning to continue your work after you are found to be roadkill?

I don't even want to hear this metric in a start-up, because how would you
even optimize this metric? Be glad you have something worth dying over.

~~~
dj-wonk
I see the points you are making.

Here's another way to look at it. If you care about an open source project,
you don't want it to fail if you get run over or pulled away from it.

~~~
terminado
Actually, that depends on the original motivations of the project. As a
developer, I'll frequently code up something that amounts to a small "project"
with the potential for re-use, and I might release the source of the program,
because why not?

Whether it becomes popular, or achieves continuity isn't really a motive of
that sort of stand-alone utility project. On the other hand, a number of
wildly popular open source software projects _have_ started out that way, as
small, independent side-projects.

------
lemevi
I'm surprised that a massive project like IntelliJ has only 8 critical people
on it. They must be incredibly productive.

~~~
gerbal
Intellij is developed by JetBrains and features the occasional massive
merge[1] from the non-community addition

[1] [https://github.com/JetBrains/intellij-
community/commit/5b9f9...](https://github.com/JetBrains/intellij-
community/commit/5b9f9f62eb65105b3ac769648ee12b32baaffcd0)

------
peterhajas
This algorithm assumes that a user is a person, so some of its matches are
incorrect:

\- atom \- caskroom \- mongoid \- celery \- etc.

------
dankohn1
Please take a look at the Linux Foundation's just published census of the
security risks of open source projects. Truck factor would be a great
addition.

[https://github.com/linuxfoundation/cii-
census](https://github.com/linuxfoundation/cii-census)

------
andrewnez
I've been working on a similar list, highlighting the most depended upon
projects rather than GitHub stars: [https://libraries.io/bus-
factor](https://libraries.io/bus-factor)

~~~
raziel2p
It seems really flawed - this page seems to have mixed content from different
repositories:
[https://libraries.io/packagist/illuminate%2Ffoundation](https://libraries.io/packagist/illuminate%2Ffoundation)

------
sz4kerto
Try to guess the truck factor for Java/OpenJDK or .Net, and you'll immediately
find one reason why enterprises go with that and not ... dunno, grunt.js.

~~~
adamnemecek
Trick question, for enterprise projects it's called "Maybach factor".

------
lamontcg
Another flaw with this algorithm is that it doesn't take into account if the
author is current or not. You could have a TF of 8 but 6 of those are devs who
have left the project, so your actual TF is 2, but its probably worse than
that because a good chunk of the codebase is old with no current maintainer.

