While I'm sure there is a lot that we can learn from commercial software project management, the dynamic nature of open source projects makes the overhead that Commercial software management carries with it unneeded. I think that is the point that ESR was making.
Bringing your thoughts about goals and management together, I'll blockquote some more ESR...
Can we save defining goals as a justification for the overhead of conventional software project management? Perhaps; but to do so, we'll need good reason to believe that management committees and corporate roadmaps are more successful at defining worthy and widely shared goals than the project leaders and tribal elders who fill the analogous role in the open-source world.
That is on the face of it a pretty hard case to make. And it's not so much the open-source side of the balance (the longevity of Emacs, or Linus Torvalds's ability to mobilize hordes of developers with talk of ``world domination'') that makes it tough. Rather, it's the demonstrated awfulness of conventional mechanisms for defining the goals of software projects.
Like I said in my previous diary entry, having first hand experience leads me to question much of what ESR puts forward in his papers, so I'm not going to argue any of what he says. I do tend to think that overmanagement can be more harmful to an opensource project then undermanagement... it is a bazaar afterall.