Is the Collaborative Open Source model conducive to creating bloated software?

I wrote up a tiny (not too well supported) argument here (with a follow up containing the responses of some open source users) about why perhaps the model of collaboration that is frequently employed by open source projects perhaps contributes to the pheomenon of bloated software. I realize perhaps it is impolite to not recount the entire arguments in the above two links here, but they were rather long :).

Given your experience managing programmers at ArsDigita, and looking at the follow up contributions that were made to the open source version floating around now (or any other suitable example you might think of), what are your ideas on this topic?

Does collaborative Open Source encourage developers to add extraneous features to software without providing a practical way for the end users to disable them? Is this balanced out by people on the 'other side' who actively watch for bloat? Is the "monolithic development house" model of many software companies less prone to creating increasingly bloated software?



-- Michael H., March 24, 2004

Answers

Good question! Thanks for contributing it.

Let's start with the wisdom of the ancients. Fred Brooks in Mythical Man Month, based on looking at IBM software projects in the 1960s, concluded that no software system should be designed by more than two people. Even if adding wizards to the project made it somehow more functional the inconsistencies of having different pieces come from different minds would make it harder to maintain in the long run. Brooks basically thought that two really good people should work 100 hours/week for a few years to make sure that the raft of programmers doing the implementation didn't compromise their design's integrity (he didn't say this but I guess he expected them to take a long well-earned vacation after the thing shipped).

At ArsDigita circa 1999 (i.e., when I was running it), we basically adhered to Brooks's model. There were perhaps 20 people contributing substantial modules and/or blocks of code to the system. Most of the modules and code, however, were reviewed fairly carefully by Jin S. Choi and myself before being released on photo.net or arsdigita.com and subseqently to the public. Oftentimes a module would be sent back to its author for changes that would take days to implement and/or a suggestion to replace a large block of code with a call to a slightly extended version of an existing facility. A lot of clever sweeping ideas from smart people were rejected because, at least to our eyes, they didn't seem simple or efficient enough.

Linux to some extent might have been successful due to the personal efforts of Linus Torvalds to keep the kernel consistent with his original personal design. I'm sure that he was forced to reject a lot of technically superior ideas but that perhaps the overall result was more functional for the people who adopted Linux.

Having thought about the problem while writing this response my conclusion is that open source/closed source isn't the largest factor. I would say that as long as all code is piped through one or two people, who were the original designers of the system, a system will be resistant to bloat. Having a small overall team, of course, is conducive to this situation, which is perhaps why Microsoft goes to tremendous lengths to keep dev teams small. As soon as code can be released through a committee process or the original designers move on to something else, entropy and bloat take over.

-- Philip Greenspun, March 25, 2004