In his ApacheCon keynote last week, Doc Searls, talked about the role of modularity, with insights that he's gained during his year long study of Do It Yourself (DIY) IT. He drew heavily on some ideas from Stewart Brand's How Buildings Learn (the reading list just got taller), particularly the contrasts between magazine vs vernacular architecture and high-road vs low-road construction. He introduced these concepts by using the state of the Alexis Park as a case study, and then branched out from there.

Here are some of the good quotes I was able to capture:

"Linux is free if your time has no value"
"the job of the architect is to bankrupt the builder"
"all buildings are predictions, and all predictions are wrong"
"form follows funding"

Doc feels that a good way to look at the software industry is to look at the construction industry and look for parallels. He views open source software as vernacular architecture and low-road construction. And based on what I learned about those terms, I'd probably agree with that.
He noted that when we build a house, it doesn't usually stay the way it was built, but that it gets rebuilt over time, and that the modularity of construction materials allows this to happen and increase the amount of DIY involved. His argument is that

the chief ideal isn't openness - it's modularity

I found this all to be very interesting and reasonable. Although there are differences. Construction materials are not as malleable as software. You can't just get more construction materials, but once you have a piece of software, duplicating is trivial (modulo legal concerns).

The thing that kind of bothered me is that the argument is all about materials. If your materials have particular properties, modularity, openness, licensing, etc, then that's all that is necesary. However, in my view open source is about more than just the materials. I point (for the nth time) at Yochai Benkler's article Coase's Penguin, which abstracts the notion of commons-based peer production from its instantiation as open source software. The properties of the materials do affect the degree to which a field is amenable to commons-based peer production, but they are not the only factor. The ability to match people with tasks, the peer production part, is just as important as getting the properties of the material right. This refers to the "community" aspects of open source projects. When I asked Doc about this issue during Q&A, he didn't have a lot to say --which is fine -- we're all learning and exploring together here. I do think that looking at the peer-production/community side of the problem is as important as looking at the materials/commons side of the problem. The organization and mobilization of people who are savvy at the essentials of peer-production is an important part of the future of open source software and commons-based peer production efforts of every sort.