Oliver, I'm curious what parts of the article would you not agree with?

I'm not sure about the not agreeing, it's just that I haven't tried making things work the way you describe. I understand the merits of your "let everybody write his/her part of the setup" philosophy, but I fear than in practice the goal may not really be reached that way. You might argue that it's a good point if every developer feels obliged to do as much work on the setup process as he/she can, as close to the point of implementing a new piece of functionality as possible, and I second that. But (as I'm sure you are aware) the finer issues of setup building are really all the thousands of system incompatibilities, the subtleties of different module combinations that the user may choose... and I don't see every developer working on this stuff in between the "normal" work he/she does. I don't even see any useful way he/she could even do that kind of work, because a completely different additional work environment would be needed for that. You actually mention as much in your article when you say "there will always be developers who specialize in solving the more intricate setup issues".

The result is: this approach may lead to a decrease of setup related issues and to a tighter integration of the setup building process in the overall product development phase, and that's a good thing. But I can't help but wonder how much of an advantage that really is, because the points where one single developer will ever have to add a file to the setup (for example) will be far between and he'll probably make a mess of it, or forget it altogether. So maybe a work order to tell someone about it at that same point would serve better, I don't know. Sure, he may forget about that just as well, but I guess he's less likely to because it's less work for himself.

If you want the main moral to be "try including the setup process in overall development instead of seeing it as an unwanted annex", I'm with you all the way.