Slashdot Mirror
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).
I think there are bigger issues going on than if an open source project dies if someone gets hit by a truck.
Seriously, you guys think that some stupid piece of software is more important than human life...
old news.
Going 10-10
So we take a stupid buzzword, link to its Wikipedia.... call it news for nerds. Then lets discuss? Really?
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
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 are much more likely to be killed or raped by an illegal immigrant than run over by a truck. True a disproportionate number of truck drivers are in fact illegal immigrants who do not give a darn about the motoring public; However you are still more likely to be killed by a non truck driving illegal immigrant than a truck driving illegal immigrant.
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.
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.
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 Homebrew by a lot. Being able to make a build script for top for example doesn't mean you can maintain the homebrew project itself.
Cwm, fjord-bank glyphs vext quiz
Who really gives a flying fuck?
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.
involve the truck being driven by another developer on the project?
I guess it's like putting all your eggs in 3 baskets.
USD on the other hand must be close to TF=INF for practicality.
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.
I was hoping for news on the fuck tractor and when it's coming to my town.
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?
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.
bitcoin has a TF of only 3.
All projects start at TF1
Japanese for "death from overwork".
Human Rights, Article 12: Freedom from Interference with Privacy, Family, Home and Correspondence
Imposter Syndrome, perhaps?
WTF people? There is already a term for this and it involves getting hit by a BUS, not a truck.
Now get off my lawn.
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). SoylentNews, on the other hand, uses a fork of Slashdot's software that has been fixed to have better Unicode support.
with a dozen or so employees
All but one will be involved with 5 year planning, meetings, programs, trips, conferences, all the "fun" things.
The one employee (usually a guy with a tech background) will have all the "scut work" dumped on them. Stuff like accounting / bookkeeping, paying the bills writing the checks, the donor and grantmaking and fundraising mailing lists, keeping the network and computers running in spite of facebook and twitter. Processing credit card and ACH donations, web site updates, everything nobody else wants to do
When this guy reaches 62 and retires, panic and disorder ensue. Hint to governing boards: If all of the first category are women, you can bet they pulled the "I am offended temper tantrum" stunt to shirk their share of the hard work. Board needs to impose cross-training mandates NOW, before the loss of this single employee makes you look like a bunch of horse's backsides.
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.
I've known business analysts, testers and stake holders who were just as if not more vital to a project than any one of the developers.
Build a Man a Fire, and He'll Be Warm for a Day. Set a Man on Fire, and He'll Be Warm for the Rest of His Life.
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 that didn't actually interact (the Osborn computer included bundled software worth more than the actual computer, a big selling point), but Framework was fully integrated, including its own development environment and desktop. It was essentially Windows before Windows, built on much better technology (similar to the "Lisp environment machines", but on normal hardware).
Unfortunately Tate died of a heart attack shortly after its introduction (around 1984, the Macintosh year). He had a vision for the product and was basing the company's future on it, but unfortunately everyone else had the mindset of running a database application company, and had no idea what to do with this thing. Rather than treating and promoting it as the new platform for a whole ecosystem of new software (basically an OS), they treated it as just another application, and while it had the potential to be the dominant OS before Windows was even finished, it eventually became just another forgotten Windows application.
Around here all I have to worry about are soccer moms in minivans and rich snobby women driving Teslas to Neman Marcus. Not so much trucks. My projects are safe. For now.
So, what would be the truck factor of systemd?
Remember that it doesn't absolutely need to be a truck, a hellfire missile would do the trick as well...
captcha: flatten