3 ms·

This analysis seems to me to be deeply flawed. At only a glance, at least two of the projects mentioned at TF=2 have entire companies that are dedicated to the

This analysis seems to me to be deeply flawed. At only a glance, at least two of the projects mentioned at TF=2 have entire companies that are dedicated to them: ansible and elastisearch. According to Crunchbase, Elastic.co has between 51 and 200 employees, and has raised over $104MM in venture capital. According to Github, there are at least 27 employees of Ansible, Inc. that have commit access to github. Even if we assume that many of these people are not "core developers", saying that the "truck-factor" is /2/ is so far from accurate as to go from merely wrong to straight-up deceitful.

hobarrera 11y ago
> This analysis seems to me to be deeply flawed. At only a glance, at least two of the projects mentioned at TF=2 have entire companies that are dedicated to them: ansible and elastisearch. Even if there's an entire company behind it, that doesn't mean that everybody at that company is an expert in that software. Maybe just one or two devs had a good understanding on how it works, and the rest work on different things, document, or maybe just know it superficially.
- hlieberman 11y ago
  It stretches credulity to believe a $100MM+ company only has two developers who are an expert in the software -- especially when it's their most important product.
mpdehaan2 11y ago
It seems bogus, yes. Since you mentioned a project I started - ansible, and I am no longer with the company and stopped working on the project as a result of that, you could consider that me one of those truck hit. While the number of Ansible company folks on the core team is about 3 or 4 now (much of the company is devoted to Ansible Tower as a product), I think ansible's truck factor is about infinite though, because the code isn't complicated, and any user could pick it up, the code is pretty safe from any event. The license is stuck as GPL due to no copyright assignment (100% intentional!), though 'ansible' in context is trademarked. So people shouldn't be worried. The code will live, because it's basic stuff that hundreds of python developers can get their heads around (and do, based on a lot of long-tail contributions). So, unless I'm full of it, it was designed to survive ANYTHING, on purpose, and especially sought out making the code non-clever, and make it easy enough for someone to hack where they needed to extend or diverge from what we did with it. Code that has a liability based on a disappearing author is usually the complex code, in a specific problem domain, or something complex and poorly documented or poorly commented, or built with proprietary tools. Ansible is none of those things. If it were deep AI code in C or Intercal attached to a domain that had nothing to do with AI and uncommonly used C or Intercal in that field, maybe! And if something is useful enough enough, it can pretty much surive anything - or at least be easily replaced. That being said, there's reason to worry about dependencies - but I think those are seldom because of the factors in this article. Here's a post on some of those I wrote recently: http://opsrevolution.com/its-3am-do-you-know-where-your-software-dependencies-are/ http://opsrevolution.com/its-3am-do-you-know-where-your-soft... TLDR - The only TF=2 we should be worried about is probably Team Fortress related. If you must be worried, be worried when projects have small numbers of contributors and you don't understand the code - and don't think anybody else also using the project would pick it up. If you think there's 1000 people who understand it and can pick it up, it's definitely not TF=2 and this whole article is bad math.

hobarrera 11y ago

> This analysis seems to me to be deeply flawed. At only a glance, at least two of the projects mentioned at TF=2 have entire companies that are dedicated to them: ansible and elastisearch. Even if there's an entire company behind it, that doesn't mean that everybody at that company is an expert in that software. Maybe just one or two devs had a good understanding on how it works, and the rest work on different things, document, or maybe just know it superficially.

hlieberman 11y ago
It stretches credulity to believe a $100MM+ company only has two developers who are an expert in the software -- especially when it's their most important product.

mpdehaan2 11y ago

It seems bogus, yes. Since you mentioned a project I started - ansible, and I am no longer with the company and stopped working on the project as a result of that, you could consider that me one of those truck hit. While the number of Ansible company folks on the core team is about 3 or 4 now (much of the company is devoted to Ansible Tower as a product), I think ansible's truck factor is about infinite though, because the code isn't complicated, and any user could pick it up, the code is pretty safe from any event. The license is stuck as GPL due to no copyright assignment (100% intentional!), though 'ansible' in context is trademarked. So people shouldn't be worried. The code will live, because it's basic stuff that hundreds of python developers can get their heads around (and do, based on a lot of long-tail contributions). So, unless I'm full of it, it was designed to survive ANYTHING, on purpose, and especially sought out making the code non-clever, and make it easy enough for someone to hack where they needed to extend or diverge from what we did with it. Code that has a liability based on a disappearing author is usually the complex code, in a specific problem domain, or something complex and poorly documented or poorly commented, or built with proprietary tools. Ansible is none of those things. If it were deep AI code in C or Intercal attached to a domain that had nothing to do with AI and uncommonly used C or Intercal in that field, maybe! And if something is useful enough enough, it can pretty much surive anything - or at least be easily replaced. That being said, there's reason to worry about dependencies - but I think those are seldom because of the factors in this article. Here's a post on some of those I wrote recently: http://opsrevolution.com/its-3am-do-you-know-where-your-software-dependencies-are/ http://opsrevolution.com/its-3am-do-you-know-where-your-soft... TLDR - The only TF=2 we should be worried about is probably Team Fortress related. If you must be worried, be worried when projects have small numbers of contributors and you don't understand the code - and don't think anybody else also using the project would pick it up. If you think there's 1000 people who understand it and can pick it up, it's definitely not TF=2 and this whole article is bad math.