Ember.js Truck Factor

[gavelino]

As part of my PhD research on code authorship, we calculated the Truck Factor (TF) of some popular GitHub repositories.

As you probably know, the Truck (or Bus) Factor designates the minimal number of developers that have to be hit by a truck (or quit) before a project is incapacitated. In our work, we consider that a system is in trouble if more than 50% of its files become orphan (i.e., without a main author).

More details on our work in this preprint: https://peerj.com/preprints/1233

We calculated the TF for Ember.js and obtained a value of 6.

The developers responsible for this TF are:

Robert Jackson - author of 48% of the files
Peter Wagenet - author of 20% of the files
Charles Jolley - author of 19% of the files
tomhuda - author of 11% of the files
Stefan Penner - author of 8% of the files
Martin Munoz - author of 7% of the files

To validate our results, we would like to ask Ember.js developers the following three brief questions:

(a) Do you agree that the listed developers are the main developers of Ember.js?

(b) Do you agree that Ember.js will be in trouble if the listed developers leave the project (e.g., if they win in the lottery, to be less morbid)?

(c) Does Ember.js have some characteristics that would attenuate the loss of the listed developers (e.g., detailed documentation)?

Thanks in advance for your collaboration,

Guilherme Avelino
PhD Student
Applied Software Engineering Group (ASERG)
UFMG, Brazil
http://aserg.labsoft.dcc.ufmg.br/

[ef4]

(a) Do you agree that the listed developers are the main developers of Ember.js?

Not really. Charles Jolley hasn't been actively involved for a long time -- he's just the last person to touch many stable parts of the infrastructure that have been very slow-changing.

tomhuda is really two people (@wycats @tomdale).

Everyone else listed is definitely a "main developer", but there are quite a few other people who have enough knowledge to navigate and maintain the codebase. At risk of forgetting someone, I will point at @krisselden, @ebryn, @machty, @mixonic, @trek, and myself (@ef4).

(b) Do you agree that Ember.js will be in trouble if the listed developers leave the project (e.g., if they win in the lottery, to be less morbid)?

No. In addition to the other half of the core team that I listed above, we have a large set of contributors scattered across many companies, many of whom could step in and keep the project alive.

I think your methodology is overweighting edits, which is understandable since they're measurable. But Truck Factor really depends more on reads. That is, you need people who have read the code and understand it. Sometimes those people may only have reached in to make very small, targeted changes. But their reading time is what allows them to add to the truck factor.

[ef4]

e.g., if they win in the lottery, to be less morbid

This is open source. If somebody wins the lottery, I expect to see more contributions, not fewer. :-p

[jonnii]

@ef4 depends if you have wifi on your new yacht

[stefanpenner]

@ef4 depends if you have wifi on your new yacht

what sort of lottery would buy me a yacht without wifi

[stefanpenner]

(b) Do you agree that Ember.js will be in trouble if the listed developers leave the project (e.g., if they win in the lottery, to be less morbid)?

I don't believe the project would fail, as we have a very healthy distributed and vibrant community. I suspect in the short term loss of context would cause some pain, but I believe the community would adapt.

The biggest lose, may not be measured, and that is the vast amounts of issue triage and release related work @rwjblue does. @krisselden deep problem solving skills, @wifelette ability to organize and promote the community and conferences etc. (The list of important, maybe not directly visible via GH commits contributors goes on).

@gavelino it may be interesting to attempt to take "measure" contributions in other dimensions, such as the issue tracker, related projects, core team minute meetings, RFC submissions, and addon maintainership.

Measuring more dimensions would likely be costly, but if possible may yield some interesting pieces.

[runspired]

@ef4

This is open source. If somebody wins the lottery, I expect to see more contributions, not fewer. :-p

Agree, If someone would pay me (or if I won the lottery) pretty much the only thing I'd do is OS.

[runspired]

Also the argument on reads is strong, Ember's source is very readable and while I've not contributed I know my way around it decently well and am reliably familiar with many of it's parts. If the entire core team suddenly abandoned the project to go live on a big island in the sun, I wouldn't think very hard before deciding to start working on it myself.

[wifelette]

For the sake of risk mitigation, we can discuss codifying some rules.

Specifically, Ember Core Team Members are forbidden from buying lottery tickets Thus, continuity is assured.

[trek]

Obviously no IRB will give you permission to test this experimentally (although for the sake of science any of us would dutifully accept a winning lottery ticket), but it might be interesting to track down examples where main or primary authors have left in the past.

https://github.com/openexchangerates/accounting.js - for a year @josscrowcroft was floating down a river somewhere in the world.

https://github.com/jashkenas/backbone and https://github.com/jashkenas/underscore - @jashkenas was away for quite some time. Backbone seems is doing well, many underscore users shifted to https://github.com/lodash/lodash, and the two projects are now merging

https://github.com/pluginaweek/state_machine the authors stopped work on this two years ago. Despite this it's still listed as the #1 recommendation for state machines on ruby toolbox. The project essentially lives on with a new set of authors at https://github.com/state-machines/state_machines

[gavelino]

Thank you for the answers. I really appreciate the feedback.

Our research is under development and the answers we are receiving for this survey will help to better interpret the results and improve our approach.

[stefanpenner]

@gavelino awesome, best of luck!