This is about free software, the Free Software Foundation (FSF), and various similar projects. Our project here at SocialTechnology.ca is not only going to include a lot of free software, it is going to be (yet another) mechanism for the organization of free software projects. The significant difference between what we will be providing and what is provided by the Free Software Foundation, SourceForge.net, and other open source software initiatives will be the social element.
All software development suffers to some extent from Brooke’s Law “Adding manpower to an already late software project makes it later).
This phenomenon is well described in an essay by John Drummond who notes:
“Brooke’s Law states that programming work performed increases with direct proportion to the number of programmers (N), but the complexity of a project increases by the square of the number of programmers (N2). Therefore, it should follow that thousands of programmers working on a single project should become mired in a nightmare of human communication and version control” and relates that the open source movement.
That article refers to Eric S. Raymonds famous essay “The Cathedral and the Bazaar” discussing two modes of group cooperative activity. Raymond is also the author, collector, and editor of the famous Jargon File , now in print under the name “The New Hacker’s Dictionary.” from which we may (since it is public domain) quote the whole entry:
Brooks’s Law prov.
“Adding manpower to a late software project makes it later” — a result of the fact that the expected advantage from splitting development work among N programmers is O(N) (that is, proportional to N), but the complexity and communications cost associated with coordinating and then merging their work is O(N^2) (that is, proportional to the square of N). The quote is from Fred Brooks, a manager of IBM’s OS/360 project and author of “The Mythical Man-Month” (Addison-Wesley, 1975, ISBN 0-201-00650-2), an excellent early book on software engineering. The myth in question has been most tersely expressed as “Programmer time is fungible” and Brooks established conclusively that it is not. Hackers have never forgotten his advice (though it’s not the whole story; see bazaar); too often, management still does. See also creationism, second-system effect, optimism.
“Jargon File 4.2.3” or “The on-line hacker Jargon File, version 4.2.3, 23 NOV 2000”
While we have this in mind we should look at the definitions for Bazaar and Cathedral from the same source.
bazaar n.,adj.In 1997, after meditatating on the success of Linux for three years, the Jargon File’s own editor ESR wrote an analytical paper on hacker culture and development models titled The Cathedral and the Bazaar . The main argument of the paper was that Brooks’s Law is not the whole story; given the right social machinery, debugging can be efficiently parallelized across large numbers of programmers. The title metaphor caught on (see also cathedral ), and the style of development typical in the Linux community is now often referred to as the bazaar mode. Its characteristics include releasing code early and often, and actively seeking the largest possible pool of peer reviewers.
[see bazaar for derivation] The `classical’ mode of software engineering long thought to be necessarily implied by Brooks’s Law . Features small teams, tight project control, and long release intervals. This term came into use after analysis of the Linux experience suggested there might be something wrong (or at least incomplete) in the classical assumptions.
“A Brief History of Hackerdom” by Eric S. Raymond, and “The GNU Operating System and the Free Software Movement” by Richard M. Stallman. “A Brief History of Hackerdom” by Eric S. Raymond, and “The GNU Operating System and the Free Software Movement” by Richard M. Stallman.
As Drummond points out, the free and open-source software movements have been very successful, giving us Linux and all the GNU software that usually comes with it — all done in spite of Brooke’s Law. But perhaps not as successful as they could be. The social factors are still important, and anything that could make programmers communicate better, cooperate better, and inspire each other while at the same time keeping their innate perfectionism and lack of contact with reality would probably serve to improve their output and increase the quality of their work without any of the ill effects that happen when management “suits” try to achieve that end.
This is where the technology of CASA and Intermix will come in. …
(To me this is an obvious conclusion, but it is supported by arguments and evidence scattered amongst dozens of web pages and megabytes of crude text on my hard drives, so the conclusion of this page will have to wait behind things of much higher priority, like putting up on the web the software to make this happen … — dpw)
Throughout these web pages you should note an extreme optimism about the future of CASA technology. That’s partly because most of these pages are written by a computer programmer, and as the Jargon File notes:
What a programmer is full of after fixing the last bug and before discovering the next last bug. Fred Brooks’s book “The Mythical Man-Month” (See “Brooks’s Law”) contains the following paragraph that describes this extremely well:
All programmers are optimists. Perhaps this modern sorcery especially attracts those who believe in happy endings and fairy godmothers. Perhaps the hundreds of nitty frustrations drive away all but those who habitually focus on the end goal. Perhaps it is merely that computers are young, programmers are younger, and the young are always optimists. But however the selection process works, the result is indisputable: “This time it will surely run,” or “I just found the last bug.”.
True as this may be, there is more than optimism behind SocialTechnology.ca and its projects. There is genuinely new and powerful technology, based on mathematics and computer science, on the one hand, and a great many of the discoveries of psychologists and sociologists over the past century. It will be argued that the latter have been less successful than they could have been because they have seen themselves as scientists doing capital-S Science, when they should have been doing Technology. For more on this point see the page contrasting Science and Technology, or Doug Wilson’s page on academic territories.
For more information on this technology, see our (nascent) webpages on “How It Works”, and for the skeptical, “Does It Work?”
Copyright © 2000 Douglas P. Wilson