Calculating the Truck-Factor of Popular Open Source Projects
An anonymous reader writes: The Truck Factor describes the minimal number of developers that have to be hit by a truck (or quit) before a project is incapacitated. Wikipedia defines it as a "measurement of the concentration of information in individual team members. A high truck factor means that many individuals know enough to carry on and the project could still succeed even in very adverse events." The term is also known by bus factor/number. In this article, the authors calculate the truck factor for 133 popular GitHub applications. Spoiler, but unsurprising: Linux ranks near the top (meaning that it's highly resilient).
It's morbid as hell, but for anyone who works with, or hell RELIES, any of the packages at the TF1 level, if any freak accident happens, you could be fucked bad.
It's morbid, but it's something we all need to consider with any software project.
Non impediti ratione cogitationus.
Over 15 years ago Segfault.org reported their classic: "What If Linus Torvalds Gets Hit By A Bus?" - An Empirical Study. If we learned anything from that, it's that we also have to watch out for muffins.
Craft Beer Programming T-shirts
Not as f*cked as the dev that was hit by the truck, you insensitive clod!
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
I wanted to run this on my own GitHub hosted project. But the "article" has nothing but a huge link to a LICENSE and README file.
Bummer.
You know what's significantly worse than an Open Source project with TF1? A closed source project with a TF1.
I once joined a project where one of the core developers had mysteriously disappeared. He had been one of the early designers, and was the only person who actually knew how his areas worked.
It took a small team about a year to fully understand all of his work, but the project survived. To this day, four years after his disappearance (three after his body was pulled from a river), we still find some code with his name on it, and it's a tradition to assign it to the newest team member to read, understand and deliver a report on how it works. It's a rough process, but we got through it eventually.
His legacy on the project is as an object lesson in the necessity of good commenting, and a reminder to management that they must be wary of one-man teams.
You do not have a moral or legal right to do absolutely anything you want.
OK, if it makes you feel better, we'll call it the "Girl Factor". That's the number of developers who have to discover girls before the project is incapacatated.
Actually, by all relevant measures any important software project can more important than a human life. That is not nice, but it is reality. That we usually do not have to sacrifice human life to keep software projects going is nice and I am all for it. It is however a luxury we have because circumstances allow it. But look at Karshi for example, and you will find that this is not universally true even in modern and more enlightened times.
But that is not what this story is actually about. It is about contingencies and insurance.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
That should be "Karoshi" with a bar over the "o". Cut&paste did not work...
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Why buy the horse when you get the milk for free?
And what happens when the free milk gets hit by a truck?
Mod me down, my New Earth Global Warmingist friends!
Maybe we should be asking what's the truck factor (or is that nuclear strike factor?) of Github. What's the effect of developers centralizing on on the ONE opensource hosting site? Seriously what happens when Github is incapacitated by say a malicious state actor (put your favorite cyberbaddy here)? I know it's git, so there should be "mirrors" everywhere for the big projects (which have a high truck factor to begin with). So TF has to be divided further by the resiliency of the host site.
Truck Factor is more related to losing developers key to a project to a point the project can' t be satisfied with the assigned budget or time constraints.
In the case of Open Source Software, if the project is popular enough, at much the project will be delayed until new developers can understand the code, but that's about it. Everything is there for anyone to continue the work and there are no time or budget constraints.
It's actually less of a concern than it is with small vendor closed source...
There have been a few small software vendors where the company owner or core developer was killed, which then resulted not only in the ceasing of development, but also in the source code either being lost or tied up in legal disputes for years.
For something that's open and has user interest, it can be forked and development can be continued by someone else...
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
It's morbid as hell, [...]
To avoid the morbid feeling, I prefer a different wording: "Lottery factor", meaning when someone wins the lottery, cashes the money and never comes back. I imagine the person living on a personal tropical paradise without any access to the internet. So this person won't be reachable, won't contribute but is not dead but enjoys life. Same effect, less morbid.
It's actually less of a concern than it is with small vendor closed source...
There have been a few small software vendors where the company owner or core developer was killed, which then resulted not only in the ceasing of development, but also in the source code either being lost or tied up in legal disputes for years.
A much bigger problem with closed source software: The company making it gets bought by its largest competitor, usually the exact product and company you tried to avoid, which then kills the product you were using and tries to force all the costumers to convert.
OK, if it makes you feel better, we'll call it the "Girl Factor". That's the number of developers who have to discover girls before the project is incapacatated.
Most of the developers that I know are more likely to get hit by the truck.