3 ms·

Very interesting. But that probably doesn't translate to professional projects where people have more incentive to contribute and core contributors the obligati

Very interesting. But that probably doesn't translate to professional projects where people have more incentive to contribute and core contributors the obligation to onboard and mentor new hires...

convolvatron 7y ago
indeed. i dont think its wise to dismiss the corporate aversion to 'heroes'. while its certainly possible to make an outsized contribution without getting burned out or devaluing other contributors, thats often not what happens.
- nitrogen 7y ago
  devaluing other contributors Maybe this isn't what you meant, but why is it that human beings see someone they know producing a lot of value as diminishing the value produced by others, especially in technical matters?
  - wolco 7y ago
    Because people compare and if someone is doing a lot morr than everyone else it makes everyone look bad. Why? Because the mba will see a metric elevated and use that to define a norm. Now they only want to hire 10x performers. They don't know how to find them so they invent this complex hiring process that filters out so many good candidates they have no chance of ever finding that 10x developer. They settle on the fake 10x who speaks well and presents all of the right signals. The dev comes in and struggles and blames the code/past developer/way something is done and claims a rewrite is needed in a new and trendy language. This prompts a huge rewrite that takes place over a year at the end of which its determined that nothing works and that project gets cancelled. By this point that developer has been promoted to your manager.
- diminoten 7y ago
  Isn't this paper saying exactly the opposite, though? That it does happen, and quite often?
falcongod082 7y ago
If you think that "why" someone contributes is meaningful, I'm curious how you think that professional projects (whatever that means) and whatever arbitrary metric is being used to encourage incentive would give a different result.
- jrumbut 7y ago
  For instance, on a minuscule open source project of mine, I wrote all the code and another developer has (kindly) stepped up and managed upgrades to one of the dependencies, bumping the version number when it's time to do so. If he and I were employed together to work on this project, a workload distribution of me writing and maintaining the entire codebase (minus one line) and him coming by every couple months to update a version number would not be a very fair or realistic division of labor. The open source development process is very different from anything else. None of my projects at work have a long tail of contributors submitting comment typo fixes.
  - diminoten 7y ago
    It'd be much more fair if the project at your job started out as a proof-of-concept that you wrote, while the other dev worked on other things. Once your proof-of-concept grew into something management wanted, you'd probably still be writing a lot of the code, and the other developer would be contributing, but in the realm of 20% of the codebase, at least to start (and according to this article, that wouldn't change).
    - jrumbut 7y ago
      You're right, and I don't doubt the value of studying open source projects or that it's the best that can be done given the data available, but there are limitations on how much light this data can shed on the great mass of code being written within organizations. Maybe the results do apply to the situation you describe, I'd be curious to know that.
- jeandejean 7y ago
  I'd say two things, the first is that if you're not paid, you don't have that much incentive to contribute hardly so it's no surprise that most OS projects are maintained by a handful of (great indeed) highly motivated developers. Second is that it's something widely known that developers are not flexible, so if they're in charge of their baby, they won't make so many efforts to encourage outsiders contributions. Whereas in a corp environment, managers and other devs should make sure it doesn't become an obstacle to contributions. That's not very precise but I think people can relate to what I said.
jcriddle4 7y ago
"...In 2018, Agrawal...studied...661 open source and 171 in-house proprietary projects. In that sample, over 89% of all projects were hero-based..." In theory a "professional" project would want efficiency so all developers contributing fairly equally however the data does not support that. Wide variances in developer productivity are widely documented. I would think open source projects also have to work to onboard and mentor new developers or they would eventually die out. You might say that professional projects are possibly larger but the study indicated size didn't matter "...the bug injection distributions of heroes and nonheroes is barely changed after stratifying the data according to project size. Hence, when discussing the external validity of these conclusions, we need not explore issues of team size and hero prevalence." I don't see any data that suggests this study would not generalize to professional projects.

Very interesting. But that probably doesn't translate to professional projects where people have more incentive to contribute and core contributors the obligation to onboard and mentor new hires...

convolvatron 7y ago

indeed. i dont think its wise to dismiss the corporate aversion to 'heroes'. while its certainly possible to make an outsized contribution without getting burned out or devaluing other contributors, thats often not what happens.

nitrogen 7y ago
devaluing other contributors Maybe this isn't what you meant, but why is it that human beings see someone they know producing a lot of value as diminishing the value produced by others, especially in technical matters?
- wolco 7y ago
  Because people compare and if someone is doing a lot morr than everyone else it makes everyone look bad. Why? Because the mba will see a metric elevated and use that to define a norm. Now they only want to hire 10x performers. They don't know how to find them so they invent this complex hiring process that filters out so many good candidates they have no chance of ever finding that 10x developer. They settle on the fake 10x who speaks well and presents all of the right signals. The dev comes in and struggles and blames the code/past developer/way something is done and claims a rewrite is needed in a new and trendy language. This prompts a huge rewrite that takes place over a year at the end of which its determined that nothing works and that project gets cancelled. By this point that developer has been promoted to your manager.
diminoten 7y ago
Isn't this paper saying exactly the opposite, though? That it does happen, and quite often?

falcongod082 7y ago

If you think that "why" someone contributes is meaningful, I'm curious how you think that professional projects (whatever that means) and whatever arbitrary metric is being used to encourage incentive would give a different result.

jrumbut 7y ago
For instance, on a minuscule open source project of mine, I wrote all the code and another developer has (kindly) stepped up and managed upgrades to one of the dependencies, bumping the version number when it's time to do so. If he and I were employed together to work on this project, a workload distribution of me writing and maintaining the entire codebase (minus one line) and him coming by every couple months to update a version number would not be a very fair or realistic division of labor. The open source development process is very different from anything else. None of my projects at work have a long tail of contributors submitting comment typo fixes.
- diminoten 7y ago
  It'd be much more fair if the project at your job started out as a proof-of-concept that you wrote, while the other dev worked on other things. Once your proof-of-concept grew into something management wanted, you'd probably still be writing a lot of the code, and the other developer would be contributing, but in the realm of 20% of the codebase, at least to start (and according to this article, that wouldn't change).
  - jrumbut 7y ago
    You're right, and I don't doubt the value of studying open source projects or that it's the best that can be done given the data available, but there are limitations on how much light this data can shed on the great mass of code being written within organizations. Maybe the results do apply to the situation you describe, I'd be curious to know that.
jeandejean 7y ago
I'd say two things, the first is that if you're not paid, you don't have that much incentive to contribute hardly so it's no surprise that most OS projects are maintained by a handful of (great indeed) highly motivated developers. Second is that it's something widely known that developers are not flexible, so if they're in charge of their baby, they won't make so many efforts to encourage outsiders contributions. Whereas in a corp environment, managers and other devs should make sure it doesn't become an obstacle to contributions. That's not very precise but I think people can relate to what I said.

jcriddle4 7y ago

"...In 2018, Agrawal...studied...661 open source and 171 in-house proprietary projects. In that sample, over 89% of all projects were hero-based..." In theory a "professional" project would want efficiency so all developers contributing fairly equally however the data does not support that. Wide variances in developer productivity are widely documented. I would think open source projects also have to work to onboard and mentor new developers or they would eventually die out. You might say that professional projects are possibly larger but the study indicated size didn't matter "...the bug injection distributions of heroes and nonheroes is barely changed after stratifying the data according to project size. Hence, when discussing the external validity of these conclusions, we need not explore issues of team size and hero prevalence." I don't see any data that suggests this study would not generalize to professional projects.