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).
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.
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.
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!
Well, that's the beauty of distributed source control. Everyone who works on those projects has a complete repository of their own. The website provides a convenient synchronization point, but it's only authoritative by designation, not by any differences in the data. If there's a project on Git, and no one else has even bothered to keep a local copy of it somewhere, how much is really lost if GitHub goes away? If it's open source and no one else has even bothered to use the code anywhere else, again, how much are we losing? At that point, the project is already dead, and the general consensus is that it wasn't worth using anywhere. Not all code is really worth saving forever and ever. Hopefully GitHub is taking care to ensure that this doesn't happen, but active projects have no need to really worry.
So, I think the TF isn't really affected by the resiliency of the hosting site for distributed source control projects. The only thing it would do is potentially inconvenience developers for a time as they search for a new method/host to synchronize their development.
Irony: Agile development has too much intertia to be abandoned now.
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.
That actually sound like a decent idea: every 2 or 3 years, GitHub gets wiped (or gets archived). And then everybody who cares can push again. Will reduce the cruft and will provide an incentive to increase the Truck Factor.
The more people I meet, the better I like my dog.
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.