UC Irvine Researcher Walt Scacci is studying open source development, and has come across distinct practices.
It’s not clear to me how the open source practices differ from agile processes in general — a lighter, more conversational, less document-heavy design process.
What are some of the differences you’ve found, apart from the obvious ones?
For example, in software engineering, there’s a widespread view that it’s necessary to elicit and capture the requirement specifications of the system to be developed so that once implemented, it’s possible to pose questions as to what was implemented, compared with what was specified.
We do not see or observe or find in open-source projects any online documents that software engineers would identify as a software requirements specification. That poses the question: What problem are they solving, if they haven’t written down the problem? While it’s true that there’s no requirements specification, what there is instead is what we’ve identified as a variety of software informalisms.
What do you mean by “informalism”?
That word is chosen to help compare to the practice advocated in software engineering, in which one creates a formal systems specification or design that might be delivered to the customer. Informalisms are such things as information posted on a Web page, a threaded e-mail discussion or a set of comments in source code in a project repository. It may be a set of how-tos or FAQs on how to get things accomplished. Each is a carrier of fragments of what the requirements for the system are going to be.