There are several key features to an open source architecture:
- Designer–participants: where those who participate are also those who design the system.
- A control system that one allows oneself to be part of in order to expand that structure: an example can be found in computer games that provide modules for end-users to code and create their own, sometimes startlingly different, versions of the game.
- Choreographies for openness: group instructions that are interpreted and modified as necessary by participants, individually or collectively. To begin, established boundaries are required in order to foster creativity; this does not mean that they cannot be breached. They are placed as reference points, not to pre-define limits.
- Re-appropriation: where existing spaces, objects or actions are both fuel and catalysts for further creativity
- Capacity for sharing design problems: each person has different skills and often a problem requires a solution that can only be provided by another. A web-based example, lazyweb.org, shows how it is not important for everyone to have the technical capabilities in order to have an open source model of production.
Alternatively, cynically, in far fewer words:
- Ask the client what they want.
- Agree the brief.
- Acknowledge the budget.
- Get it to work with the site.
- Ask a builder to help construct it.
Job done. Does it seem more familiar now?