1. 14
  1.  

  2. 12

    From the abstract:

    A “hero” project is one where 80% or more of the contributions are made by the 20% of the developers.

    And the conclusion:

    Overwhelmingly, most projects are hero projects. This result holds true for small, medium, and large projects. Hero developers are far less likely to introduce bugs into the codebase than their non-hero counterparts. Thus having heroes in projects significantly affects the code quality.

    Despite the odd name (“hero”[1]) for what might more succinctly be called the “superior contributors,” (i.e., those not in the long tail) this is a Pareto distribution (or power law). It arises because voluntary cooperation will not tolerate any other distribution: none of us know more than a fraction of the knowledge in our field, all of us make the best decisions we can, and the resulting organization produces the social, technical, and material commons from which we all benefit.

    1: With one of the cited papers using the phrase “code god” for the same phenomena. so I gather they’re in like company?

    1. 1

      Yeah, this seems like more of a evidence of needing a lot of part time contributors, than a evidence of needing a few “hero” contributors.

      1. 2

        A bigger team sounds to me like a more sustainable way forward.

        Having a handful of “god” programmers can quickly turn into trouble, for example when they make bad decisions that nobody dares to question for fear of angering or turning away the few developers there are (or losing them to a fork). Being dependent on a handful of programmers also increases the risk of losing significant development capacity through, say, burnout, let alone worse things like injury or death (colloquially known as the “bus factor”).

    2. 3

      There is certainly some survivorship bias involved. The filter (50+ weeks of activity, 8+ contributors, etc) only selects somewhat successful software projects.

      Big professional software development also emphasizes reliable planning, requirements engineering, and documented processes. In contrast, most open source projects begin in a cowboy style with a single person starting to code without requirements and processes and often not even much of a plan. This lightweight process implies a lot more risk and indeed most of these projects fail. That is fine. The free software world rather goes with this evolutionary approach.

      I wonder if there is any company which works in a similar way. Start lots of projects with a fraction of the resources. Be fine with most projects failing. I guess not because this approach is hardly compatible with career development. Googles 20% rule might be considered a step in that direction.

      1. 2

        Here is an article on some companies with little to no management. There’s also collectives like Rise Up that offer services. You might also consider co-ops with little to no management. Maybe corporations or LLC’s of consultants that use the group structure to reduce liabilities while otherwise working self-directed.

      2. 4

        What I like about this research is that it disproves the Open Source propaganda that more eyeballs make better software. As a free software developer, I feel it strengthens the arguments of the Free Software movement, which is that principles and values are more important than practical implications of open code. In other words, we need to write free software not because it’s better, but because it’s good from first principles.

        1. 3

          I’m not sure that actually follows. In natural language writing, there’s usually one principle author and several editors, because reading and finding mistakes is a different skill from writing. After all, eyeballs and fingers are different body parts.

          For another thing, it really doesn’t match up with my day-to-day experience. Even when OSS projects have one principle author, they tend to be willing to fix security flaws more quickly and more thoroughly than closed-source projects, mostly by necessity. It’s a rare OSS project that would pull some of the nonsense closed-source projects are able to get away with.

          And, finally, according to Code Complete, code inspection has a higher defect detection rate than basically any other known defect detection method.

          1. 2

            Regarding code inspection, field evidence goes back at least to the 1970’s supporting that. Fagan formalized it for big companies with consistently good results.

        Stories with similar links:

        1. Why Software Projects need Heroes (Lessons Learned from 1000+ Projects) via mpweiher 6 months ago | 5 points | 2 comments