Calculating the Truck-Factor of Popular Open Source Projects 79
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).
Re: (Score:3)
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.
Re: (Score:1)
Fuck your software projects, I'm already dead! I don't care!
Re: morbid story is morbid (Score:4, Funny)
Re: (Score:2)
Not as f*cked as the dev that was hit by the truck, you insensitive clod!
He's done fucking, unless they send his body to the "You stab 'em, we stab 'em again" necrophiliac mortuary.
Re: (Score:3)
Why buy the horse when you get the milk for free?
And what happens when the free milk gets hit by a truck?
Re: (Score:1)
Is the concept of mammalian nipples foreign to you?
Re: (Score:1, Insightful)
ReiserFS?
Re:morbid story is morbid (Score:5, Insightful)
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...
Re:morbid story is morbid (Score:4, Insightful)
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.
Ashton-Tate Framework (Score:2)
This actually happened at an important point in software history. Under founder George Tate, Ashton-Tate ("Ashton" was marketing fiction) was one of the few software companies competitive with Microsoft, although they had a different initial focus (desktop databases). They finally went head to head when Ashton-Tate bought Forefront, which was developing an integrated office suite, before Microsoft had fully committed to the concept.
There had been office suites of a sort before, generally bundles of software
Re: (Score:2)
Re: (Score:3, Interesting)
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.
Re:morbid story is morbid (Score:5, Funny)
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.
"Girl Factor" hit procps (Score:1)
She turned into a wife! Being a hard-core Catholic, she popped out 10 kids! This turns out to reduce hacking time.
On the bright side, at least I made copies of nerd DNA.
Re:morbid story is morbid (Score:5, Funny)
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.
Re:morbid story is morbid (Score:4, Insightful)
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.
Re: (Score:3)
That should be "Karoshi" with a bar over the "o". Cut&paste did not work...
Definition (Score:2)
Re: (Score:2)
Exactly.
Re: (Score:2)
The Slashdot admins have an irrational fear of bidirectional characters, and neither a blacklist nor a whitelist can calm them.
Re: (Score:2)
Ah, I see. Thanks for the hint!
Moderation spoofing (5:erocS) (Score:2)
2002 is when Slashdot administrators deliberately broke Unicode to plug a exploit that used right-to-left control characters to spoof comment scores (demonstrated here [slashdot.org]). SoylentNews, on the other hand, uses a fork of Slashdot's software that has been fixed to have better Unicode support.
Re: (Score:2)
You may not want to think about it, but you are going to die sometime. That's it. A lot of people are afraid of death. I have no fear of death, because I know it is inevitable. The philosopher Thomas Nagel wrote in his work "Mortal Questions" that death, was a part of living. So you should view death as "completing the totality of your existence".
Maybe a better example for nerds, I'm watching "Space:1999" right now on broadcast TV . . . dubbed in German! Anyway, for some reason, a planet of folks bec
Re: (Score:2)
Completely fucking orthogonal.
Stop spouting shit if you don't understand it.
Re: (Score:2)
no, it's related. Think about it.
Old news (Score:5, Informative)
Over 15 years ago Segfault.org reported their classic: "What If Linus Torvalds Gets Hit By A Bus?" - An Empirical Study [segfault.org]. If we learned anything from that, it's that we also have to watch out for muffins.
Re: (Score:2)
we hope that this study will eventually be published in peer-reviewed Linux publications such as Linux Journal and Slashdot. Well, Linux Journal.
I like how even in 2000 /. apparently was already garbage.
Where is the code? (Score:3)
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.
Re: (Score:2)
Could be worse (Score:5, Insightful)
Re: (Score:3)
Close source TF1 goes bust: "Unfortunately this happens sometimes, but at least we get to sue the company for damages"
Open source RF1 goes bust: "You used FOSS for this project? How could you have been so irresponsible?!"
To be fair, that was 5 years ago, and my last few clients (large corporations) are wising up to this particular risk. When they buy software, they do assess the risk of the
Re: (Score:1)
TF1 (disambiguation) (Score:2)
How many people would need to get hit by a bus to end maintenance of Valve's closed-source Team Fortress 2? Two? Because one thing's for certain: Valve can't count to three.
Tragic, but not catastrophic (Score:5, Interesting)
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.
Re:Tragic, but not catastrophic (Score:5, Funny)
Maybe next time, just ask him to explain his code instead of killing him and throwing him in the river.
Re: Tragic, but not catastrophic (Score:2, Funny)
Have you read the code?
It was all the team could do.
Re: (Score:3, Funny)
Man, I've heard of places with tough code review sessions, but I have to say this is too much!
Okay, okay, I'll make sure my comments in my code are actually readable...
Re: (Score:1)
Maybe they asked but he refused. Increasingly brutal methods of information failed, they dumped him into river and proceed with actions described. Ever since the cidez delivered by teams have documentation and are actually commented(overlaping but nit the same).
Re: (Score:2)
Larger projects? (Score:2)
It would have been more interesting to see major projects like Apache/http, gcc or core python and perl but I expect they had an easy way to pull their data from GitHub. It also reads like a rejected academic paper. It should have started out the list stating that TF=1 is bad and TF>1 is better.
Homebrew makes a lot of sense (Score:2)
At first I wasn't sure if it was the OS X package manager or the Vagrant VM... okay it's the package manager.
That makes a LOT of sense. Many of those package install scripts are handled by someone dedicated to that project who wants it working on their Mac. So there's hundreds of different build scripts with a large variety of project maintainers. In this case they'd probably be better off separating the build script authors from the main project authors, that would probably drop the track factor of Home
Truck factor of Github? (Score:3)
Re: (Score:2)
Re: (Score:2)
Instead of a truck (servers don't typically go walking around or for a drive in the country) perhaps AWS needs a Simian Factor ? http://whatis.techtarget.com/d... [techtarget.com]
Re:Truck factor of Github? (Score:4, Informative)
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.
Re:Truck factor of Github? (Score:4)
How many of those scenarios (Score:2)
involve the truck being driven by another developer on the project?
Truck Factor is meaningless in OSS (Score:3)
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.
Greetings, Focus-Group. (Score:2)
Is Dice Holdings just floating this story in order to get quality feedback on how to justify their next attempt at seizing "abandoned" projects on SourceForge?
Re: (Score:2)
bus factor
Politically incorrect. Busses: good. Trucks: bad.
Re: (Score:2)
It's Sunday. There are no buses. (Source: fwcitilink.com)
Why is it always developers (Score:2)
Re: (Score:1)
My projects are safe. (Score:1)