Software Projects and Heroes: Lessons Learned from GitHub Projects

Re:Software Projects and Heroes: Lessons Learned from GitHub... by jrumbut on Sunday April 28, 2019 @03:03PM (#19772991)

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.

[ Parent | on HN ]

Re:Software Projects and Heroes: Lessons Learned from GitHub... by diminoten on Sunday April 28, 2019 @03:14PM (#19773075)

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

[ Parent | on HN ]

Re:Software Projects and Heroes: Lessons Learned from GitHub... by jrumbut on Sunday April 28, 2019 @04:03PM (#19773351)

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.

[ Parent | on HN ]