# Usman Haque and granularity

I recently met Usman Haque in London and got the chance to talk with him about his work and I'll be trying here to make an article about it.

Usman Haque is a Bartlett graduated architect who tries to increase human participation in architecture. Too many people confuse technology and interaction he says, himself always trying to create some human engaging interaction more than determinist technology.
The ambiguity consist then in using the same tools than the illusion of so called intelligent environments. Humans are far more adaptable than the technique. That is why he designs environment where sensors, instead of being considered as owners of an inherent logic, tend to propose what seems to be an irrational behaviour which must be learnt indistinctly by humans in order to control it. This is how he tries to achieve to change relationships between people and their environment and also change the way urban designers are conceiving this same environment.
In fact, he develops the concept of granularity as the resolution of different entries to the system:

There are two important limits to the idea of a collaborative design system in architecture. First, the more "open" a system is, the more bewildering it is for those who are introduced to it anew. In a design system in particular, people are often aided at first, not hindered, by having constraints applied to them -- the real key is to find a way that the constraints are not necessarily absolute: if the constraints themselves can be modified over time then that really helps in fostering on-going participation. The user-configured comment-moderating system employed by Slashdot.org is a good example of this process. Second, I don't believe that it's possible to construct a "totally open system" -- the very nature of a "system" (which is a description of a set of relationships, dependent in all cases upon a particular subjective approach) precludes it. There will always be processes that involve "top-downness" and "bottom-upness" -- the key to helping perpetuate the design and evolution of such environments is to ensure that the relationship between the two is not frozen.
In this context it's important in particular to ensure a varied *granularity* of participation: different people have different interests or skillsets, are willing to participate to a greater or lesser degree, or desire to effect smaller or larger impact on the entity being constructed. Everyone will have their own point at which they wish to engage with something, so it's vital that a wide variety of entry points is available.

This is actually the basis of a manifest for an open source urban design he wrote with the writer/programmer Matthew Fuller, called Urban Versioning system (read below).

Open Burble

Reconfigurable house

Evolving sonic environment

Floatabales

Urban Versioning System 1.0.1

By Matthew Fuller and Usman Haque
(this is a small version but you can read longer one HERE)

Preamble

The production of structures to articulate, produce and protect space, often coded under the disciplinary term 'architecture' is arguably one of humanity's oldest activities. Countless technologies and legal frameworks have grown along with this process. Formerly one of the most collaborative endeavours, architecture now often functions in opposition to such collaboration.

Matthew Fuller and Usman Haque, a writer and architect respectively, propose that a lesson can be learned for architecture from the way in which software is made. Here, they concentrate on the current most significant mode of software development, Free, Libre and Open Source Software (FLOSS). The rigorous set of approaches to software development in FLOSS, formulated as a set of freedoms, are here suggested as a point of inspiration.

The Free Software Definitioni states that free software contains the following freedoms articulated as an ethical rule-set. Since they are a set of contractual terms, they are set out as such

• The freedom to run the program, for any purpose (freedom 0).

• The freedom to study how the program works, and adapt it to your needs (freedom 1). Access to the source code is a precondition for this.

• The freedom to redistribute copies so you can help your neighbour (freedom 2).

• The freedom to improve the program, and release your improvements to the public, so that the whole community benefits (freedom 3). Access to the source code is a precondition for this.

A number of attempts have been made to transfer such principles to the making of objects. Often this has been done on the basis of plans, recipes, diagrams and other such 'genotypic' information. The key question here is how such strategies apply or can be modified to apply to the production of architecture.

In architecture there is no substance that is concurrently both "editable source code" (genotype) and "usable artefact" (phenotype). Though some have usefully argued that architectural drawings can be considered "source" and therefore it is the design process that must be opened up,ii one of the most interesting aspects of open source software is the continuous interleaving of production, implementation, usage and repurposing processes, all of which can and sometimes must be open – not just an "open design" that then gets implemented in a closed manner. Such an approach changes the place of aesthetics in architecture to one not of form, but of organisation.

We propose a license for the open source design and construction of cities. The Urban Versioning System quasi-license is not yet such a license. At the moment the document is more a dogma or set of constraints. It’s an oath, a quasi-license, something to chew on. It does not base itself on the genotype / phenotype split, though the distinction can be made: we want to see what happens if we work otherwise.

The Urban Versioning System quasi-license proposes the following seven initial constraints.

Seven Constraints

1. Build rather than design

We propose a new model for the production of cities, where design and planning are abandoned in favour of beginning immediately with building and construction. This new adhocismiii requires us to disregard any temptation to sketch, to plan, to model and above all to discard any desire to "brainstorm". All these activities can be performed on the actual materials we wish to build with, while the thought-processes directly engage with or become the lived-in artefact, articulated at a 1:1 scale.

Constructing right from the start erodes distinctions between design, modelling, construction and inhabitation. To design and build concurrently requires simultaneous tenancy. The building is the model. It enables us to produce real spatial situations we otherwise only imagine, and makes it possible for interested people to enter into, critique and add to what we is being realised in the world. We can discuss with materials – not representations of materials – and negotiate around connection points and the means of connection, rather than proffering a completed structure as a whole.

The problem is that architectural design can often simply be a process of predicting problems, removing obstacles and resolving all possible contradictions: the best situation, from the perspective of such an architect, is to have project documentation that is so complete that every aspect of construction (and occupancy) has been articulated and specified so that the eventual building construction contractor needs make no on-site decisions and simply has to follow orders to the letter. This process often leaves no room for future adaptation.

Building continuously rather than designing makes it clear that buildings are dynamic, responsive and variable and would encourage the development of robust technological frameworks that unite design, construction and occupancy.iv

2. Materials must come pre-broken

A seamless package is frustratingly daunting when it comes to enabling others to participate in the design and development of an artefact. However, a broken system is usually one that attracts the most attention, in part because it appeals to others' desire to "repair" and also because breaks can enable one to understand better how something should or could work.

With respect to opening up the urban design/construction process, and encouraging the reuse and repurposing of architectural artefacts, it is important to ensure that such structures and systems are released in a pre-broken condition. This might take one of several forms.

Materials that readily decompose can be said to be ecologically pre-broken. Those which rapidly decompose to a basic elemental or organic state, such as ice, iron, wood and silica rather than complex materials involving a high amount of adulteration are particularly interesting. Building with such materials requires constant innovation, replenishment and reconstruction and emphasises the ephemerality of architectural constructs, helping to counteract the usual architectural obsession with permanence.

Materials that are readily repairable, interrogable or hackable can be said to be pre-broken in terms of their use. Broken structures are not meant to last, they encourage reuse and repurposing and enable people to participate at a number of levels, depending on skills, desire and ambition. Failing this, power tools, hairpins and nail files prove useful in opening things up.

3. Make joints

We understand joints not only to be the things that hold things together, but also as the means by which an object connects to its outside and allows it to dream. We are interested in joints which function as forcing points of abstraction.

The joint is a point, conceptual as much as material, at which powers are mediated and confronted, the part that conjoins, spreads and transforms tensions. To continue our parallel with computing, interfaces, protocols, interpreters, compilers and screens are kinds of joints. Joints are entry points for supporting, contrasting or even opposing systems. Concentrating on the production of joints presupposes future amalgamation or integration with things, events and systems that are yet to occur.

A threshold is not a joint, a joint draws thresholds towards it. As such the joint is the structure’s defence against entropy, against simply becoming a pile. In doing so it allows the structure to conjugate both symmetry and asymmetry. Asymmetry of materials and of forces, and where wanted or found, symmetry of structure.

All entities under the UVS quasi-license must have more than one open joint available at any time. Opening but a single joint at any time will simply result in 'chain' structures. Two, three or more, result in a workable range of degrees of freedom.

4. Rubbish is the root of virtuosity

The more granularity an instrument offers the more it establishes the capability of proficient as distinct from perfunctory performance, and from there, the means by which it establishes a trajectory of possibility to infinite levels of brilliance. In this generosity, it also sets up an abundant capacity for incompetent performance. Equally, in releasing any construction to open development, it must be appreciated that design preciousness can result in aggravation and disappointment: the entity that you have nurtured since birth will be manipulated, botched and improved by others in ways that, if you retain sensations of ownership, might be difficult to bear.

People will, collaboratively, take a design in directions you could never have imagined, sometimes in ways that you think are utterly wrong. In order for the constraints associated with ownership not to impose such heartbreak, objects made under the UVS quasi-license are constrained to preserve a clear pathway that participants in builds can take. As in old guilds or current games, they would pass various levels from beginner/introductory/informal participation all the way to advanced/sophisticated/virtuoso participation. Free software projects often have a clear hierarchy of involvement and ways of making a contribution that require different levels of skills, from the relative beginner to the high-level expert. Modularity in this sense means arranging the development of a project in a way that allows productive involvement from large to small scales, from brief to long term periods, and that, in terms of expertise, encourages participation ranging from beginner to high-levels of sophistication.v

There is a meaningful granularity of participation that drives the most successful FLOSS projects. Whilst such qualities allow for multiple kinds of productive involvement, what is often missed in accounts of these structures is that in allowing for finely granular participation and incrementally difficult problem-setting, these projects also act as large scale learning environments. This would be quite a good definition for a city.

[note MB: the ‘Rubbish’ in the title does not discernibly reappear in the text. Needs explaining] ?-- UH: see new para at beginning of this section

5. Collaborate with collaborators

One way in which the question of objects and code is often articulated is that code allows for non-rivalrous use. A piece of software can be copied as many times as wanted without any loss of quality and without denying anyone else the ability to make such a copy. This is seen as being a key difference between the world of bits and that of atoms. Yet rivalry can find itself played out at many distinct scales.

An interesting consequence of the kinds of collaboration developed in FLOSS has been that enemies find themselves working on the same project. Companies who are in at least nominal rivalry with each other may build their businesses around shared code or use the sharing and development of such code as a way of developing an alternative platform to proprietary software in order to gain market share.

More notably, those in conflict in other ways may find themselves working together. Anarchists might find themselves contributing to a code-base also worked on by the United States military.

Such paradoxes are replayed in terms of construction in the interplay between the static and the changeable, between the learning built into interrogable technologies and the things that are taken for granted in designed ease of use. Builds using the UVS quasi-license will shelter and defend this paradox of collaboration, and be as much nurtured as they are confounded by it.

6. Copying or not copying is irrelevant

The UVS quasi-license recognises that the world is constructed by its inhabitants, at every moment of conception, inception and perception. When we talk about the public domain, we understand that the public is not some pre-existing fact. Publics must be made, indeed publics make themselves, and in so doing publics make domains that they refer to and through which they are mutually constitutive. The spatial technologies of such publics interweave fluctuating participation and capacities for organisational coherence.

The do-it-yourself (DIY) approach has been popularised, even pimped, recently by television shows which chart the progress of projects undertaken by homeowners or show how design professionals can advise people in upgrading existing homes themselves.

Rather than shying away from the conceptual difficulties offered by a system in which "anyone" can be a designer; where "copies" are as flawless as an "original"; where preciousness is not a desirable attribute; architects could embrace these concerns and seek ways to narrow the divide between the “designer” and the “designed-for”. Embrace the culture of the knock-off and of improvement.

The architect in this situation is therefore many things, not simply locatable in a single professional. The architect becomes a diagramming force, paradoxically both rule and rule generator determining the axioms that run through the process. Rather than being being locked into gatekeeping, this figure unleashes processes, encourages the flow of possibilities and modalities, works in a specific fashion on particular problems with certain sets of knowledge, learns and is often taken by surprise through the process.

7. Property must be invented

What we contemporarily understand as property is only what has been settled as such. Arguments that property takes on any particular natural form are unhelpful. Its visible artificiality is what makes it useful. What we encourage is an understanding of property as plastic, as historically contingent, and something to be experimented with or left as redundant. This means that there is no blueprint, provided by FLOSS or anything else, to follow religiously. It is a given that property is theft.

What we propose here is that the vocabulary of property generated by capitalism, especially in its neoliberal variants, is too rigid to allow for invention. In its application it has also proven itself to be incapable of allowing for a sustainable, let alone fully ecological, relationship between the societies it organizes and the life systems of the planet. In its application to the context of digital abundance, it has failed on its own terms, let alone those of the development of a viable and delightful digital culture. FLOSS has shown, in the domain of software, a way in which systems of property may be manipulated in order to set out a more pragmatic, useful and productive mode of operation.

All UVS builds must open the category of property up to their own speculative reinvention. These are not predetermined. Only a mode of construction that is capable of losing the plot is adequate.

---------------

This build is licensed under the Urban Versioning System v.1.0

This work is licensed under the Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

i Free Software Foundation, The Free Software Definition, online at, http://www.fsf.org/licensing/essays/free-sw.html

For useful reflections on Free Software see, Christopher M. Kelty, Two Bits, the cultural siginificance of Free Software, Duke University Press, Durham NC, 2008

ii Dennis Kaspori, "A communism of ideas: towards an architectural open source practice", Archis #3, 2003; See also, The Open Architecture Network, http://www.openarchitecturenetwork.org/. Kaspori, often in collaboration with artist Jeanne van Heeswijk has developed some very significant moves towards a participatory architectural and planning practice, for instance in the Face Your World project which involved hundreds of people over several months in the redesign of a park in the Slotervaart suburb of Amsterdam http://www.faceyourworld.nl/. An early text which develops the political reading of architecture and open source software in a useful way is Brian Carroll, Open Source Architecture, online at, http://www.nettime.org/Lists-Archives/nettime-l-0006/msg00036.html

iii Charles Jencks & Nathan Silver, Adhocism, the case for improvisation, Anchor Press, London 1973

iv Extended Environments Markup Language, (http://www.eeml.org/) by one of the authors, is one attempt to extend IFC by describing the dynamic behaviour of sensors and actuators.

v This is the argument that is put forth in various ways the in following texts and elsewhere: Yochai Benkler, The Wealth of Networks, Yale University Press, 2007; Daren C. Brabham, "Crowdsourcing as a model for problem solving: an introduction and cases", Convergence, the international journal of research into new media technologies, Vol 14, no.1 feb 2008, pp.75-90; Jeff Howe, "The Rise of Crowdsourcing", Wired, Vol. 14 No.6, online at, http://www.wired.com/wired/archive/14.06/crowds.html; Geert Lovink & Cristoph Spehr, 'Out-Cooperating The Empire?' in, Geert Lovink and Ned Rossiter eds., My Creativity Reader, a critique of creative industries, Institute of Network Cultures, Amsterdam, 2007, pp.81-96; Cristoph Spehr, The Art of Free Cooperation, Autonomedia, New York, 2007