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 email 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.
If they're put together in such a haphazard way, can they really be considered requirements?
Yes and no. Clearly, they're distributed, but in order for people to contribute to the project, those people need to understand where those requirements are and how they relate to each other and how to pull them together. Part of how the community works is that each of the participants discusses what the system should do in whatever informalism they feel is the most appropriate to them.
Once the requirements are figured out, how are systems designed in open source?
We've begun to codify the practice we observe with the label "continuous design". That would mean, much like requirements, that there is no unique baseline design, necessarily. Instead, there is today's understanding of the design, which may be different from yesterday's or tomorrow's. It's not a bounded activity with a fixed and targeted deliverable, but an ongoing activity, and the system design is represented across the Web of these informalisms. The key point is the evolving nature of it.
