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).

22 of 79 comments (clear)

  1. Re:morbid story is morbid by RyuuzakiTetsuya · · Score: 2

    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.
  2. Old news by Coryoth · · Score: 4, Informative

    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.

  3. Re: morbid story is morbid by BarbaraHudson · · Score: 3, Funny

    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.
  4. Where is the code? by friedmud · · Score: 2

    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.

  5. Could be worse by thaneross · · Score: 5, Insightful

    You know what's significantly worse than an Open Source project with TF1? A closed source project with a TF1.

    1. Re:Could be worse by JaredOfEuropa · · Score: 2

      Depends. If you are a manager responsible for a service that relies on the TF1 project, there are two scenarios.
      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 vendor going out of business and weigh that against the impact of losing the software. When they use open source, they implement a strategy to mitigate that risk, by identifying alternatives, or by assessing the feasibility to provide continued support of the software with in-house resources or external consultants.

      --
      If construction was anything like programming, an incorrectly fitted lock would bring down the entire building...
  6. Tragic, but not catastrophic by Sarten-X · · 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.

    --
    You do not have a moral or legal right to do absolutely anything you want.
    1. Re:Tragic, but not catastrophic by davester666 · · Score: 5, Funny

      Maybe next time, just ask him to explain his code instead of killing him and throwing him in the river.

      --
      Sleep your way to a whiter smile...date a dentist!
    2. Re: Tragic, but not catastrophic by Anonymous Coward · · Score: 2, Funny

      Have you read the code?
      It was all the team could do.

    3. Re: Tragic, but not catastrophic by Anonymous Coward · · 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...

  7. Re:morbid story is morbid by NoNonAlphaCharsHere · · Score: 5, Funny

    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...

    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.

  8. Re:morbid story is morbid by gweihir · · Score: 3, 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.

    --
    Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
  9. Re:morbid story is morbid by gweihir · · Score: 2

    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.
  10. Re:morbid story is morbid by binarylarry · · Score: 2

    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!
  11. Truck factor of Github? by aNonnyMouseCowered · · Score: 2

    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.

    1. Re:Truck factor of Github? by Dutch+Gun · · Score: 3, 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.

      --
      Irony: Agile development has too much intertia to be abandoned now.
    2. Re:Truck factor of Github? by Beezlebub33 · · Score: 3

      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.
  12. Truck Factor is meaningless in OSS by goruka · · Score: 2

    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.

  13. Re:morbid story is morbid by Bert64 · · 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...

    --
    http://spamdecoy.net - free throwaway anonymous email - avoid spam!
  14. Re:morbid story is morbid by geggo98 · · 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.

  15. Re:morbid story is morbid by Carewolf · · Score: 3, 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.

  16. Re:morbid story is morbid by ShanghaiBill · · Score: 4, 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.