Another component, I think, is the difference between being able to work on whatever you want vs. having to follow a roadmap dictated by project leadership. Oth

Another component, I think, is the difference between being able to work on whatever you want vs. having to follow a roadmap dictated by project leadership. Other commenters have touched on this (pointing out the decline of community orientation, rise of corporate oversight, or the fading glamour, for example), but no one has identified it directly. The article points out that we collectively re-examined Brook's rule, going from "adding more engineers to a project makes it ship later" to "if you need to get more work done, go attract more contributors." I think the evidence shows it's more nuanced. If you have a large amount of potential tasks and a large pool of potential contributors, and little strong preference for which tasks get done (OSS in the 90's maybe) then highly self-motivated people can pick up work they find interesting or which are useful for them. You can then avoid the exponential explosion of communication/coordination overhead by empowering those individual contributors to make their own decisions about how that work should be done. This is how OSS can scale to hundreds of contributors. Once you introduce some sort of top-down planning that dictates which tasks are important, the blessed approaches, strict coding patterns etc. then you demotivate a large number of contributors who don't share the top-down priorities and you have to pay the exponential overhead cost of distributed coordination to enforce the top-down priorities.