Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Open Source Software Stats Linux

Calculating the Truck-Factor of Popular Open Source Projects 79

Posted by timothy from the keeping-linus-safe-from-assassination dept.
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).
This discussion has been archived. No new comments can be posted.

Calculating the Truck-Factor of Popular Open Source Projects More

Calculating the Truck-Factor of Popular Open Source Projects

Comments Filter:

  • Old news (Score:5, Informative)

    by Coryoth ( 254751 ) on Saturday July 11, 2015 @08:34PM (#50091067) Homepage Journal

    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)

      by fisted ( 2295862 )

      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)

    by friedmud ( 512466 ) on Saturday July 11, 2015 @08:56PM (#50091163)

    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.

  • Could be worse (Score:5, Insightful)

    by thaneross ( 853469 ) on Saturday July 11, 2015 @09:05PM (#50091207)
    You know what's significantly worse than an Open Source project with TF1? A closed source project with a TF1.
    • 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

      • Re: (Score:1)

        by Anonymous Coward
        Exactly who do you sue in a TF1 company? The truck driver?

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

    by Sarten-X ( 1102295 ) on Saturday July 11, 2015 @09:07PM (#50091219) Homepage

    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)

      by davester666 ( 731373 ) on Saturday July 11, 2015 @09:39PM (#50091331) Journal

      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)

        by Anonymous Coward

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

        • Re: (Score:3, Funny)

          by Anonymous Coward

          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)

        by Anonymous Coward

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

      • Bookmarking this post for the next time someone tries to argue that black humor is never funny.

  • 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 Home

  • Truck factor of Github? (Score:3)

    by aNonnyMouseCowered ( 2693969 ) on Saturday July 11, 2015 @10:23PM (#50091495)
    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.

    • Re: (Score:2)

      by x0ra ( 1249540 )
      On the same idea, what's the truck factor of AWS ?

    • Re:Truck factor of Github? (Score:4, Informative)

      by Dutch Gun ( 899105 ) on Sunday July 12, 2015 @04:00AM (#50092147)

      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.

  • involve the truck being driven by another developer on the project?

  • Truck Factor is meaningless in OSS (Score:3)

    by goruka ( 1721094 ) on Saturday July 11, 2015 @11:53PM (#50091737)
    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.

  • 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?

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

Slashdot Top Deals

Avoid strange women and temporary variables.

Close