Andrea Rosada Architettura Open Source by Andrea Rosada

Indice Ringraziamenti

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Introduzione

I Mondo Open

1 Open Source

1.1

1.2

Internet e WWW . . . . . . . . . . . . . . . . . . . . . . . . .

1.1.1

Internet

. . . . . . . . . . . . . . . . . . . . . . . . . .

1.1.2

Il funzionamento della rete . . . . . . . . . . . . . . . .

1.1.3

Il Web . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.1.4

Il personal computer

. . . . . . . . . . . . . . . . . . .

1.1.5

Hackers

. . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

1.2.1

Dal free software all'Open Source Free software

. . . . . . . . . . . . . . . . . . . . . . .

1.2.2

Open Source . . . . . . . . . . . . . . . . . . . . . . . .

1.2.3

Anarchia organizzata . . . . . . . . . . . . . . . . . . .

1.2.4

Reputazione e collaborazione . . . . . . . . . . . . . . .

1.2.5

ModularitĂ e ricombinazione . . . . . . . . . . . . . . .

2 Open Design 2.1

Dal bit all'atomo

31 . . . . . . . . . . . . . . . . . . . . . . . . .

2.1.1

Non solo software . . . . . . . . . . . . . . . . . . . . .

2.1.2

Dal bit all'atomo

. . . . . . . . . . . . . . . . . . . . .

2.1.3

Fab . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.1.4

Open Design

2.1.5

Casi esemplari di Open Design e Open Hardware

. . .

2.1.6

Arduino

. . . . . . . . . . . . . . . . . . . . . . . . . .

2.1.7

Il processo dell'Open Design . . . . . . . . . . . . . . .

2.1.8

Open-X

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

INDICE

II Architettura Open Source

3 Architettura aperta

3.1

3.2

Processo e utente . . . . . . . . . . . . . . . . . . . . . . . . .

3.1.1

Opera aperta

3.1.2

La ne dell'architetto demiurgo

3.1.3

L'utente all'interno del processo edilizio . . . . . . . . .

3.1.4

Strumenti di coinvolgimento . . . . . . . . . . . . . . .

Architettura aperta . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.2.1

Alexander e il `pattern language'

. . . . . . . . . . . .

3.2.2

Habraken e i `supports' . . . . . . . . . . . . . . . . . .

3.2.3

Friedman e il ` atwriter'

. . . . . . . . . . . . . . . . .

3.2.4

Il metodo Segal . . . . . . . . . . . . . . . . . . . . . .

4 Architettura Open Source 4.1

4.2

4.3

4.4

Il dibattito contemporaneo . . . . . . . . . . . . . . . . . . . .

4.1.1

Primi contributi all'Architettura Open Source

. . . . .

4.1.2

Il dibattito attuale

. . . . . . . . . . . . . . . . . . . .

4.1.3

Una de nizione ancora aperta . . . . . . . . . . . . . .

Lettura di un fenomeno emergente

. . . . . . . . . . . . . . .

4.2.1

Iniziative di Architettura Open Source

4.2.2

Un corpus di esperienze eterogeneo

Casi studio

. . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.3.1

Open Architecture network

. . . . . . . . . . . . . . .

4.3.2

Open Structures

4.3.3

OpenSimSim

4.3.4

Air Tree Commons

4.3.5

Open Source Ecology . . . . . . . . . . . . . . . . . . . 117

4.3.6

WikiHouse . . . . . . . . . . . . . . . . . . . . . . . . . 122

. . . . . . . . . . . . . . . . . . . . . 105

. . . . . . . . . . . . . . . . . . . . . . . 109 . . . . . . . . . . . . . . . . . . . . 113

Considerazioni generali . . . . . . . . . . . . . . . . . . . . . . 128 4.4.1

Temi e campi di applicazione

. . . . . . . . . . . . . . 128

4.4.2

L'Architettura Open Source come strumento . . . . . . 129

4.4.3

Oltre l'emergenza e i Paesi in via di sviluppo?

4.4.4

PossibilitĂ e ettive di applicazione

. . . . . 130

. . . . . . . . . . . 132

III Strumenti operativi dell'Architettura Open Source 135 5 Strumenti operativi 5.1

139

Il progetto della sorgente . . . . . . . . . . . . . . . . . . . . . 139

INDICE

5.2

5.3

5.1.1

Sorgente uguale apertura . . . . . . . . . . . . . . . . . 140

5.1.2

Ricombinazione e modularità

5.1.3

Dal bit all'atomo

. . . . . . . . . . . . . . 141

. . . . . . . . . . . . . . . . . . . . . 142

Il progetto di gestione della comunità . . . . . . . . . . . . . . 143 5.2.1

Figure e ruoli

5.2.2

Auto-organizzazione e autorialità

. . . . . . . . . . . . . . . . . . . . . . . 144

5.2.3

Organizzazione modulare della comunità

. . . . . . . . . . . . 145 . . . . . . . . 147

Il progetto della piattaforma . . . . . . . . . . . . . . . . . . . 148 5.3.1

Strumenti e pratiche

. . . . . . . . . . . . . . . . . . . 149

5.3.2

Oltre il repository . . . . . . . . . . . . . . . . . . . . . 150

5.3.3

Piattaforma e interazione . . . . . . . . . . . . . . . . . 151

6 Applicazione pratica 6.1

6.2

BrickShell

153

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

6.1.1

Obiettivi, ipotesi iniziali e adozione dell'Open Source

. 157

6.1.2

Tema e campo di applicazione . . . . . . . . . . . . . . 158

6.1.3

De nizione della sorgente . . . . . . . . . . . . . . . . . 158

6.1.4

De nizione della comunità . . . . . . . . . . . . . . . . 160

6.1.5

De nizione della piattaforma . . . . . . . . . . . . . . . 161

6.1.6

Svolgimento . . . . . . . . . . . . . . . . . . . . . . . . 163

Utilità della sperimentazione . . . . . . . . . . . . . . . . . . . 173 6.2.1

BrickShell: Architettura Open Source . . . . . . . . . . 173

6.2.2

BrickShell: sorgente progettuale . . . . . . . . . . . . . 176

6.2.3

BrickShell: comunità di pari . . . . . . . . . . . . . . . 178

6.2.4

BrickShell: piattaforme di supporto . . . . . . . . . . . 180

6.2.5

BrickShell: considerazioni generali e risultati . . . . . . 181

Conclusioni e sviluppi futuri Transcalarità

185

. . . . . . . . . . . . . . . . . . . . . . . . . . . 185

Un nuovo ruolo per l'architetto? . . . . . . . . . . . . . . . . . 186 Il dibattito continua

. . . . . . . . . . . . . . . . . . . . . . . 186

Open Source e pratica professionale . . . . . . . . . . . . . . . 188 Conclusioni

. . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

Ringraziamenti Una tesi sull'open source non puĂ˛ che basarsi su tanti contributi diversi e con gurarsi come un continuo processo di mutuo apprendimento. Per questo motivo devo ringraziare le persone che ho avuto la possibilitĂ di incontrare nel mio percorso di ricerca. Pierre-Alain Croset ha accolto l'idea della tesi con entusiasmo e curiositĂ , fattori che, oltre ai consigli preziosi e alle attente disamine scienti che e disciplinari, hanno contribuito enormemente allo sviluppo del mio lavoro. Ă&#x2C6; vero che la ricerca scienti ca Ă¨ questione di metodo, ma Ă¨ ancor piĂš vero che Ă¨ questione di atteggiamento e spirito critico: vederlo all'opera con gli studenti, i colleghi e con me Ă¨ stato (ed Ă¨) un continuo motivo di stimolo intellettuale. Un importante ruolo, prima ancora che iniziassi a lavorare in Dipartimento, lo hanno avuto Stefano Pujatti, Valeria Brero, Corrado Curti e Daniele Almondo e tutta l'allegra banda di cascina Giardina. Aver avuto la possibilitĂ di lavorare e confrontarmi con loro Ă¨ per me motivo di grande orgoglio e crescita professionale. Mario Sassone mi ha dato la possibilitĂ di mettere a punto gli strumenti de niti durante il lavoro di ricerca attraverso l'organizzazione e la gestione del workshop BrickShell. Grazie a lui e a Tomas Mendez Echenagucia, Iasef MD Rian, Shaghayegh Rajabzadeh e a tutte le persone che vi hanno partecipato (studenti e ospiti) ho avuto modo di sperimentare nella pratica ciĂ˛ che no ad allora era solo teoria, compiendo quello che reputo un passo decisivo per l'avanzamento della mia ricerca. Angela Lacirignola ha messo a disposizione il laboratorio LATEC, il suo tempo e le sue energie per permetterci di portare a termine la costruzione di BrickShell. Enrico Bo a, Ilaria Ariolfo, Matteo Malandrino e Antonio Spinelli insieme con gli studenti, i docenti membri e i coordinatori del collegio DAPe sono stati, attraverso il loro lavoro e le loro critiche, una fonte inesauribile di spunti e ri essioni. Alastair Parvin, Tatjana Schneider, Francesco Cingolani e Daniel Dendra, seppur in brevi incontri, hanno contribuito ad approfondire la mia conoscenza su molti dei casi che ho preso in esame. JENGA! e /LAM sono stati spazi di confronto e maturazione che, anche se lontani dai temi di ricerca, hanno avuto e continuano ad avere un ruolo importante per quanto riguarda l'attivitĂ professionale e la mia visone dell'architettura. In ne debbo ringraziare la mia famiglia e soprattutto Laura, il cui supporto quotidiano Ă¨ stato fondamentale.

Introduzione Sono giunto al termine di questa mia apologia del romanzo come grande rete. Qualcuno potrĂ obiettare che piĂš l'opera tende alla moltiplicazione dei possibili piĂš s'allontana da quell'unicum che Ă¨ il self di chi scrive, la sinceritĂ interiore, la scoperta della propria veritĂ . Al contrario, rispondo, chi siamo noi, chi Ă¨ ciascuno di noi se non una combinatoria d'esperienze, d'informazioni, di letture, d'immaginazioni? Ogni vita Ă¨ un'enciclopedia, una biblioteca, un inventario d'oggetti, un campionario di stili, dove tutto puĂ˛ essere continuamente rimescolato e riordinato in tutti i modi possibili. Ma forse la risposta che mi sta piĂš a cuore dare Ă¨ un'altra: magari fosse possibile un'opera concepita al di fuori del self, un'opera che ci permettesse d'uscire dalla prospettiva limitata d'un io individuale, non solo per entrare in altri io simili al nostro, ma per far parlare ciĂ˛ che non ha parola, l'uccello che si posa sulla grondaia, l'albero in primavera e l'albero in autunno, la pietra, il cemento, la plastica... Non era forse questo il punto d'arrivo cui tendeva Ovidio nel raccontare la continuitĂ delle forme, il punto d'arrivo cui tendeva Lucrezio nell'identi carsi con la natura comune a tutte le cose?

(Calvino 1993, p. 134-135)

Internet e le tecnologie dell'informazione e della comunicazione hanno modi cato radicalmente gli ultimi decenni del XX secolo e continuano a in uenzare la nostra societĂ . Non Ă¨ cambiato solo il modo di accedere e di fruire dell'informazione ma anche il modo attraverso il quale l'informazione viene prodotta.

Infatti negli ultimi anni si Ă¨ assistito all'emergere di importanti

modelli di produzione basati sulla collettivitĂ , la collaborazione e l'organizzazione autonoma piuttosto che sulla gerarchia e sul controllo. Alcuni di questi, come l'Open Source, si sono a ermati non solo nel campo della produzione di beni intangibili, ma anche nello sviluppo di beni materiali. L'open source Ă¨ emerso a partire dagli anni Novanta del XX secolo grazie al suo successo nella produzione di software a dabile e robusto.

Que-

sto paradigma di produzione di software, generatore di programmi creati in maniera collettiva seguendo un processo in cui gli utenti sono anche (in misure di erenti) gli sviluppatori, ha sottolineato l'e cacia dei sistemi aperti organizzati su base comunitaria orizzontale rispetto agli standard proprietari, evidenziandone l'economicitĂ e la essibilitĂ di adattamento a di erenti situazioni. Nel mondo della produzione immateriale (informazioni, idee, programmi etc.)

l'Open Source Ă¨ riuscito a garantire alla collettivitĂ accesso

immediato alla tecnologia normalmente in uso, grazie a una ride nizione del processo di sviluppo e distribuzione ridisegnando i ruoli degli attori coinvolti. La s da di `aprire' il mondo sico Ă¨ perĂ˛ piĂš complessa. Il tentativo di

CAPITOLO 0.

INTRODUZIONE

capire come e se un oggetto si puĂ˛ de nire `open source' va immediatamente a toccare aspetti legati alla sua produzione sia materiale che immateriale: il materiale di cui Ă¨ fatto, come Ă¨ stato prodotto, e al contempo come Ă¨ stato ideato, disegnato, standardizzato, ma anche aspetti legati al tipo di utilizzo che Ă¨ possibile farne. In ambito architettonico la messa in pratica di queste idee rilancia una visione giĂ espressa dalle tecno-utopie qualche decennio fa e abbandonata a metĂ degli anni Settanta. Questa visione di tecnologia inclusiva si Ă¨ evoluta con l'avvento del `computer-aided design' prima, e con l'esplosione del web 2.0 in un secondo momento, usando la tecnologia come mezzo per incoraggiare la partecipazione degli utenti e per rendere i `non esperti' in grado di esprimere direttamente i loro bisogni e desideri al di lĂ , o addirittura senza la mediazione di l'architetto.

In un sistema globale sempre piĂš complesso e strati cato,

dove i ruoli e i mandati di utenti e progettisti sono sempre meno de niti (l'immagine di copertina, un'opera di Francesco Lo Savio, rappresenta bene questa situazione di inde nitezza) Ă¨ necessario ri ettere sulle implicazioni che l'evoluzione tecnologica digitale ha sull'architettura e sui cambiamenti che essa comporta. L'obiettivo di Architettura Open Source Ă¨ veri care l'ipotesi che il fenomeno Open Source sia applicabile anche all'interno del processo edilizio, attraverso la de nizione di opportuni strumenti che si basano su un uso collaborativo, aperto e partecipativo delle attuali tecnologie digitali di comunicazione. Di seguito verrĂ illustrata brevemente la struttura di questa tesi e l'organizzazione dei suoi contenuti.

Nella prima parte del lavoro si Ă¨ cercato

di dimostrare che, a partire dall'a ermarsi di Internet no al contemporaneo sviluppo delle ICT, il mondo attuale sta vivendo delle trasformazioni sostanziali, trasformazioni che possono avere dei ri essi anche nel campo dell'architettura e dei suoi metodi di sviluppo e di produzione. PiĂš che sottolineare le vicissitudini storiche, il lavoro di ricerca intende evidenziare il fatto che Internet si sia fatta vettore di aspirazioni e bisogni latenti, favorendo la nascita e lo sviluppo di fenomeni innovativi e propositivi, alternativi o comunque estranei al trend imperante basato sulla concorrenza piuttosto che sulla collaborazione.

Nel primo capitolo viene analizzato il fenomeno del-

l'Open Source come nuovo paradigma di produzione dell'informazione; nel secondo capitolo si vedrĂ come l'Open Source non si sia a ermato unicamente nel campo dell'informatica e dei software, ma abbia anche in uenzato la produzione di contenuti digitali no a interessare il mondo del design e della progettazione e produzione di oggetti.

Alla ne del secondo capitolo ci si

so ermerĂ sull'Open Design e sulle sue caratteristiche di funzionamento. All'interno dei due capitoli che compongono la seconda parte (terzo e

quarto capitolo) si ragiona sulla plausibilitĂ della tesi e sui fenomeni emergenti (tendenzialmente recenti) che si pongono come applicazioni dell'Open Source in architettura. Viene a rontato il tema della partecipazione mediata dalla tecnologia, ovvero di quelle teorie architettoniche che hanno sviluppato strumenti appositi per permettere all'utente nale di partecipare all'intero processo edilizio. Partendo da visioni e teorie sviluppatesi a partire dagli anni Sessanta del secolo scorso e arrivando no ai piĂš recenti casi di applicazione dell'Open Source, si vedrĂ come la ricerca in architettura abbia a rontato il tema dell'apertura del processo edilizio. Nel terzo capitolo viene discusso il tema dell' `opera aperta', trattato in campo architettonico da alcuni autori come Alexander, Habraken, Friedman e Segal.

Ciascuno di questi ha

messo a punto appropriati strumenti e tecniche per favorire l'inclusione e la partecipazione dell'utente nale all'interno del processo edilizio, processi e tecniche che, riletti sotto la luce del paradigma della `network society', risultano ancora attuali ed e caci. Nel quarto capitolo si a ronta il dibattito recente sull'Architettura Open Source, valutando i diversi modi con cui Ă¨ stato trattato nelle riviste di settore e dagli addetti ai lavori.

Oltre a ciĂ˛

verranno analizzate alcune delle iniziative recenti che si pongono l'obiettivo di applicare l'Open Source all'architettura, da cui Ă¨ possibile dedurre alcune considerazioni generali. Nella terza e ultima parte viene esposto il contributo originale della tesi. Attraverso lo studio del fenomeno Open Source e l'analisi dei casi studio nei capitoli precedenti Ă¨ stato possibile de nire alcuni strumenti operativi che permettono di implementare l'Open Source all'interno del processo edilizio. La necessitĂ di testarne il funzionamento e gli e etti ha portato alla realizzazione di una esperienza di Architettura Open Source a scopi didattici all'interno dell'o erta formativa del Dipartimento di Architettura e Design del Politecnico di Torino. Tale iniziativa, denominata Brickshell, Ă¨ stata il banco di prova dell'e cacia degli strumenti operativi de niti in precedenza. Nel quinto capitolo vengono elencati e illustrati gli strumenti operativi dell'Architettura Open Source, mentre nel sesto capitolo verrĂ chiarito l'utilizzo di tali strumenti, attraverso la descrizione del workshop BrickShell. In ne si conclude la trattazione presentando i risultati dell'esperienza BrickShell e alcuni possibili futuri sviluppi di questa ricerca.

Parte I Mondo Open

Le ICT [...] sono dispositivi che comportano trasformazioni radicali, dal momento che costituiscono ambienti in cui l'utente Ă¨ in grado di entrare tramite porte di accesso (possibilmente amichevoli), sperimentando una sorta di iniziazione. Non vi Ă¨ un termine per indicare questa nuova forma radicale di costruzione, cosicchĂ¨ possiamo usare il neologismo riontologizzare per fare riferimento al fatto che tale forma non si limita solamente a con gurare, costruire o strutturare un sistema (come una societĂ , un'auto o un artefatto) in modo nuovo, ma fondamentalmente comporta la trasformazione della sua natura intrinseca, vale a dire della sua ontologia. In tal senso, le ICT non stanno soltanto ricostruendo il nostro mondo: lo stanno riontologizzando.

(Floridi 2012, p. 13)

I cambiamenti che avvengono nella nostra societĂ , il paradigma tecnologico che porta alla network society, la rivoluzione digitale e la crisi economica in atto stanno portando a un radicale cambiamento dei nostri sistemi di produzione. Grazie allo sviluppo di Internet, non Ă¨ solo aumentato radicalmente il numero di informazioni che il genere umano produce e a cui puĂ˛ accedere, la nostra modalitĂ di comunicazione e di accesso all'informazione, ma si sono sviluppati anche altri metodi di produzione, alternativi o comunque di erenti rispetto ai metodi tradizionali. Se questo enorme sistema informazionale che abbiamo creato nel corso degli anni sta cambiando il nostro modo di fruire dell'informazione, di rapportarci con la cosa pubblica e con lo stato e forse, piĂš in generale, sta modi cando il nostro stile di vita, lo stesso vento di cambiamento permea quasi tutti i campi del sapere e dell'attivitĂ umana. In questi due primi capitoli si vuole dimostrare che grazie all'introduzione delle tecnologie informatiche, in particolare di Internet e del Web, ci si sta spostando da un sistema di innovazione che fa capo a un sistema centralizzato e verticale di informazione (intesa nel senso piĂš ampio e vasto del termine) a un sistema orizzontale, plurale, apparentemente caotico ma e cace e produttivo allo stesso tempo, di cui il movimento Open Source diviene esempio paradigmatico.

Capitolo 1 Open Source 1.1

Internet e WWW

1.1.1 Internet

Nato u cialmente il 1 gennaio 1983, Internet è una rete mondiale di computer interconnessi tra di loro (Internet infatti sta per INTERconnected NETworks) e assieme ad altre tecnologie (come ad esempio il GPS e la tecnologia GSM) costituisce l'infrastruttura tecnologica comunemente de nita ICT, Information and Communication Technology, attraverso cui ci scambiamo e processiamo quotidianamente informazioni. Internet è l'erede diretto di ARPANET, una rete di calcolatori interconnessi tra di loro sviluppata sotto la spinta del governo degli Stati Uniti d'America attraverso l'ARPA (Advanced Research Projects Agency) con lo scopo di collegare i calcolatori dei maggiori centri di ricerca americana per favorire lo scambio reciproco di informazioni. L'ARPA era stata fondata nel 1958 su suggerimento di James R. Killian jr., l'allora presidente del MIT (Massachussets Institute of Technology), al presidente Eisenhower il quale, allarmato dalla messa in orbita del primo Sputnik da parte dei sovietici solo un anno prima, temeva di perdere la supremazia militare e tecnologica nei confronti dell'Unione Sovietica. Eisenhower, consigliato dal Comitato di consulenza scienti ca presidenziale (Senior Advisor Committee), aveva dato

1 In questo paragrafo si fa esplicitamente riferimento, ove non indicato, al quarto capitolo del libro Libertà di software, hardware e conoscenza, di M. Berra e A. R. Meo, 2006 e al

http://www. apogeonline.com/2001/libri/88-503-1055-2/ebook/pdf/StoriaInternet.pdf. La lavoro di Carlo Gubitosa, La vera storia di Internet, disponibile all'indirizzo:

storia di Internet non è oggetto della tesi, la sua trattazione è strumentale alla redazione in quanto fornisce spunti interessanti circa i fenomeni che si sono sviluppati grazie ad essa.

CAPITOLO 1.

OPEN SOURCE

pieni poteri a Killian per la costituzione di una agenzia indipendente che potesse rivaleggiare con la potenza scienti ca sovietica, la quale aveva messo in campo un esercito di ricercatori (nell'ordine di un milione di studiosi) e, con grande probabilitĂ , aveva accumulato un grande patrimonio di conoscenze scienti che in molti campi del sapere. La convinzione poi che nel mondo della scienza, a di erenza di quello delle tecnologie applicate per la guerra o per il mercato, la chiave del successo dovesse essere ricercata nella collaborazione e non nella competizione, portĂ˛ allo sviluppo a partire dal 1969, nell'ambito della sperimentazione sul networking, di ARPANET, l'embrione di ciĂ˛ che sarebbe poi diventato Internet. ARPANET inizialmente connetteva quattro

Figura 1.1: La mappa logica di ARPANET cosĂŹ come appariva nel marzo 1977. Si possono notare i principali nodi americani facenti capo alle universitĂ e alcuni nodi europei.

L'immagine Ă¨ tratta da Wikipedia, all'indirizzo

ARPANET.

http://it.wikipedia.org/wiki/

nodi corrispondenti a quattro diverse universitĂ americane: l'UniversitĂ della California di Los Angeles, lo Stanford Research Institute, l'UniversitĂ di California di Santa Barbara e in ne l'UniversitĂ dello Utah. Nel giro di pochi anni i nodi si moltiplicarono sul territorio statunitense no a comprendere nel 1973 anche i primi nodi europei. Ad ogni nodo corrispondeva un calcolatore (detto mainframe) o un insieme di calcolatori che risultavano essere grossi piĂš

1.1.

INTERNET E WWW

o meno come un armadio e riempivano intere stanze (Figura 1.1). Il personal computer cosĂŹ come lo conosciamo ancora non apparteneva a questi anni. La storia di Internet prende piede a partire dal 1982, quando ARPAnet si divide in MILnet (rete interna al ministero della difesa e dedicata ad applicazioni militari, poi abbandonata) e in Internet (con la I maiuscola, per di erenziarla dalla sua tecnologia che porterĂ lo stesso nome ma con la `i' minuscola), e dal quel momento Internet si svilupperĂ no ad avere l'aspetto (che in realtĂ Ă¨ in continua mutazione) che tutti noi conosciamo e sperimentiamo quotidianamente.

1.1.2 Il funzionamento della rete Tuttavia un aspetto Ă¨ sempre rimasto immutato: internet non ha alcun direttorio centrale che ne guidi lo sviluppo; al contrario, la sua tecnologia viene ancora sviluppata da una comunitĂ aperta di hacker.

(Himanen 2001)

Internet Ă¨ libero.

Questa a ermazione che potrebbe sembrare pura re-

torica si basa in realtĂ su solide basi pratiche: Internet non Ă¨ di proprietĂ di nessuno (governi, imprenditori, lobby) ma Ă¨ un strumento dotato di una propria autonomia.

Autonomia che viene garantita da speci ci organismi,

quali l'Internet Engineering Task Force e l'Internet Society.

Questi, aldi-

lĂ dei nomi che potrebbero anche risultare altisonanti, sono in realtĂ delle comunitĂ aperte di cosiddetti `hackers' che sviluppano software per il funzionamento di internet. Le due comunitĂ sono totalmente aperte ed Ă¨ possibile parteciparvi anche semplicemente iscrivendosi alla loro mailing list. A dimostrazione di quanto detto si deve pensare al protocollo TCP/IP, sviluppatosi all'interno di ARPA, e alle sue alternative, x.25 e ISO, promosse dalle due maggiori organizzazioni per la standardizzazione (CCITT e ISO). Sembra che una delle cause per cui i protocolli proposti da queste due organizzazioni non abbiano funzionato e non abbiano preso il sopravvento, sia la loro natura sostanzialmente chiusa (Abbate 1999). L'esempio del protocollo TCP/IP, che Ă¨ riuscito a resistere ai tentativi di imposizione da parte di importanti organismi internazionali, dimostra come sia di cile mettere `il cappello' a Internet e alla comunitĂ che vi lavora e lo sviluppa incessantemente.

Dal

punto di vista tecnico, invece, internet funziona grazie alla commutazione di pacchetto. Quest'ultima, a di erenza della commutazione di circuito che governa l'utilizzo dei telefoni, ottimizza l'impiego della rete perchĂŠ permette a piĂš stazioni la trasmissione di diversi messaggi sullo stesso canale. La struttura di ARPANET (che sarĂ poi anche quella di internet) Ă¨ una struttura a network (Figura 1.2), ovvero una struttura simile al cervello umano, all'interno del quale i neuroni e loro collegamenti sono molteplici e sovrabbondanti,

Figura 1.2:

CAPITOLO 1.

OPEN SOURCE

Rappresentazione delle possibili con gurazioni di network.

sa su una struttura di network distribuita.

Internet si ba-

Immagine tratta da Baran, P., On distri-

buted communications networks, 1962, P-2626, RAND Corporation,

org/content/dam/rand/pubs/papers/2005/P2626.pdf.

http://www.rand.

in modo che la morte di un neurone o la caduta di un collegamento possa essere riparata attraverso l'uso di altri collegamenti (Berra & Meo 2001, p. 123). La tecnologia principale che governa il funzionamento di Internet, la commutazione di pacchetto, oggi contenuta nel protocollo TCP/IP, sfrutta esattamente questo tipo di struttura per trasmettere informazioni.

Infatti

l'informazione di base, spedita da un nodo all'altro, viene scomposta in parti (pacchetti) e ciascun pacchetto viene inviato singolarmente sfruttando i numerosi collegamenti che il network presenta tra il punto di partenza e il punto di arrivo.

Una volta a destinazione, i pacchetti vengono ricomposti

secondo l'ordine originale e l'informazione viene trasmessa.

Sfruttando le

caratteristiche intrinseche del network, l'informazione puĂ˛ dunque arrivare velocemente attraverso i canali liberi senza intasarli (dal momento che Ă¨ stata `scompattata' in piccole porzioni). Il modo attraverso cui le informazioni vengono trasmesse da un nodo all'altro attraverso internet Ă¨ interessante poichĂŠ, come si vedrĂ in seguito, ha anche degli e etti sulle modalitĂ con cui le

1.1.

INTERNET E WWW

informazioni vengono prodotte e condivise attualmente nel Web. Due forse le tappe fondamentali (ad oggi) dello sviluppo di Internet: da un lato la nascita e lo sviluppo del WWW (World Wide Web), dall'altro la di usione dei personal computer.

1.1.3 Il Web Il Web come lo conosciamo adesso Ă¨ il cosiddetto Web 2.0, ovvero Ă¨ nella fase in cui gli applicativi e le tecnologie disponibili (come ad esempio blog, wiki, social network) permettono un elevato livello di interazione con gli utenti. Questo Ă¨ dovuto principalmente a opportune tecniche di programmazione e alle relative applicazioni a erenti al paradigma del Web dinamico, in contrapposizione al cosiddetto Web statico. Blog, social network, wiki etc. hanno cambiato radicalmente non solo il nostro modo di comunicare, ma hanno anche contribuito a rivedere i processi di produzione dell'informazione. La situazione attuale non Ă¨ che l'evoluzione naturale di una delle tappe fondamentali dello sviluppo di internet, che Ă¨ sicuramente lo sviluppo del meccanismo del World Wide Web: ovvero quel dispositivo che permette, attraverso un link ipertestuale, di passare da una pagina proveniente da un sito in Italia a una pagina proveniente da un qualsiasi altro punto del globo. Questo semplice meccanismo Ă¨ stato sviluppato nel 1990 presso il CERN da due sici, Tim Bernes-Lee e Robert Cailliau, nel tentativo di organizzare meglio lo scambio di informazioni e di dati tra i vari laboratori interni al centro di ricerca europeo.

Il Web Ă¨ una creazione piĂš sociale che tecnica.

L'ho

progettato per un e etto sociale - aiutare la gente a lavorare insieme - e non come un giocattolo tecnico. Lo scopo nale del Web Ă¨ quello di sostenere e migliorare la nostra vita in Rete e nel mondo. (Berners-Lee 1999, p.123). La nascita del WWW e del protocollo http permettono, con una certa facilitĂ , idealmente a chiunque di navigare, editare e usufruire di un insieme vastissimo di contenuti collegati tra loro attraverso link. CiĂ˛ viene fatto dagli utenti grazie ai programmi detti browser (o navigatori) che ci permettono quotidianamente di navigare nel Web. Tuttavia lo sviluppo del Web Ă¨ stato possibile sia grazie al contributo degli hacker piĂš esperti e dei programmatori piĂš abili, sia anche grazie alla di usione tra tutte le persone comuni. Tale di usione Ă¨ stata dovuta principalmente alla circolazione dei personal computer che ha permesso di moltiplicare esponenzialmente il numero di nodi connessi alla rete e, di conseguenza, il numero di utenti e di servizi ad essi rivolti.

CAPITOLO 1.

OPEN SOURCE

1.1.4 Il personal computer Il primo personal computer (il nome fa riferimento all'uso personale che puĂ˛ farne il singolo individuo, in contrasto con i grandi calcolatori presenti nei centri di ricerca o nelle aziende, o con i micro calcolatori presenti sul mercato con funzioni commerciali) fu costruito nel 1976 da Steve Wozniak e venne chiamato Apple I. L'intento di Wozniak era quello di realizzare un computer che potesse essere usato da chiunque e per qualunque scopo, senza che dovesse essere speci cata una funzione particolare. Diversamente da quanto si potrebbe credere, principalmente per le fortune successive della Apple (azienda fondata in seguito dal piĂš famoso Steve Jobs), Apple I, stando alle parole dello stesso Wozniak intervistato sull'argomento, was a total accident of history. I was building projects like terminals for Hewlett-Packard and heard about a club starting up.

I designed the Apple I in a closed room in my

lab at Hewlett-Packard and in my apartment in Cupertino. I just built it for myself and started showing it o at the Club [the Homebrew Computer Club] by passing out schematics. It was like a science project I was showing o to friends. It wasn't done to be a product to be sold.

(Kennedy 1994). L'a-

spetto interessante per quanto riguarda la nascita del personal computer, che di lĂŹ a poco ebbe una larghissima di usione, Ă¨ che il progetto non nasceva con scopi commerciali, ma con scopi puramente intellettuali e scienti ci (anche se Wozniak non lavorava all'universitĂ e nemmeno era laureto al tempo) nati dalla frequentazione dell'Homebrew Computer Club, un gruppo di hacker che aveva iniziato a incontrarsi con regolaritĂ nella Bay Area a metĂ degli anni sessanta. Dice ancora Wozniak a questo proposito: I came from a group that was what you might call beatniks or hippies-a lot of technicians who talked radical about a revolution in information and how we were going to totally change the world and put computers in homes. .

Ă&#x2C6; sorprendente notare che

la costruzione del personal computer, che ha contribuito largamente al cambio di passo avvenuto nella produzione di informazione negli ultimi trenta

2 Ă¨ stato un incidente della storia.

Mi stavo occupando di progetti riguardanti dei

terminali per Hewlett-Packard e sentĂŹ dell'apertura di una nuova associazione. Progettai Apple I chiuso in una stanza nel mio laboratorio a Hewlett-Packard e nel mio appartamento a Cupertino. L'avevo costruito solo per me stesso e iniziai a mostrarlo al Club [il Homebrew Computer Club] distribuendo dei diagrammi illustrativi. Era un progetto scienti co che mostravo agli amici. Non era stato pensato per essere un prodotto da vendere. [traduzione italiana a cura dell'autore].

3 Venivo da un gruppo di tecnici chiamati beatniks o hippy che facevano discorsi

estremisti su una possibile rivoluzione dell'informazione e su come avremmo cambiato radicalmente il mondo e installato computer nelle case. [traduzione italiana a cura dell'autore].

1.1.

INTERNET E WWW

Figura 1.3: La copertina del gennaio 1983 del Time . Come in ogni primo numero dell'anno, il Time elegge la persona piĂš importante dell'anno precedente. In questo caso non si tratta di una persona, ma di una macchina: nel 1982 la macchina dell'anno Ă¨ il personal computer.Fonte:

html.

http://content.time.com/time/covers/0,16641,19830103,00.

anni (Figura 1.3), non Ă¨ stata inizialmente un'operazione commerciale

4 Tutt'altro, se si pensa che Ken Olsen, cofondatore e presidente della della Digital Equipment Corporation, ebbe a dire nel 1977: Non c'Ă¨ ragione per cui qualcuno debba volere un computer a casa propria e che questa a ermazione dĂ l'idea di come l'avvento del personal computer fosse stato interpretato dagli addetti ai lavori.

CAPITOLO 1.

OPEN SOURCE

piuttosto una fortunata e intelligente operazione amatoriale mossa da un piĂš ampio spirito controculturale che animava la Bay Area in quegli anni.

1.1.5 Hackers Prima del web, ovvero prima che ci fosse la possibilitĂ per gli utenti comuni di interagire con le tecnologie a disposizione per la creazione e la condivisione di contenuti propri, le persone che si confrontavano con la nascente internet non erano dei semplici utenti ma venivano comunemente indicati come hackers, termine che non ha una accezione negativa (come comunemente si crede) se non per l'uso scorretto che ne Ă¨ stato fatto nel tempo da parte dei mass media (il termine corretto per indicare il pirata informatico Ă¨ infatti cracker, non hacker). Infatti in quel particolare periodo molta importanza la ricoprirono non solo le innovazioni tecnologiche, ma anche le persone che vi lavoravano e il loro atteggiamento morale ed etico. Secondo Steven Levy, la storia degli hacker parte dalle prime comunitĂ di studenti appassionati di tecnologia nelle universitĂ americane nel secondo dopoguerra (in particolare la Tech Model Railroad Club TMRC, un gruppo di appassionati di modellismo ferroviario del MIT) la cui curiositĂ e applicazione nei confronti delle tecnologie elettroniche si di use in tutto il mondo (basti pensare ai radioamatori o agli appassionati di elettronica) (Levy 1996b). Oltre che prettamente orientata alla tecnica e alla tecnologia, l'espressione dei primi hacker fu sicuramente anche di natura culturale e politica, e si riferisce ai valori progettati dai movimenti sociali alla ne degli anni Sessanta e dei primi Settanta in Europa e America. Questi movimenti furuno fondamentalmente libertari [...]. Questi movimenti furono fondamentalmente culturali perchĂŠ non si concentrarono sulla presa del potere statale (a di erenza della maggior parte dei loro predecessori nel secolo) o sulla redistribuzione della ricchezza. Invece essi hanno agito sulle categorie dell'esperienza respingendo le istituzioni u ciali, alla ricerca di nuovi signi cati di vita e, conseguentemente, di una ride nizione dei contratti sociali tra individuo e stato, e tra individuo e mondo aziendale. (Castells 2001). Il contatto tra hacker (appassionati di alta tecnologia) e movimenti libertari (il cui appartenente medio potrebbe essere identi cato in un hippy delle prima ora) puĂ˛ anche sembrare forzato, o non del tutto esplicito. Scrive a tal proposito Kevin Kelly, fondatore della rivista Wired: Le origini della wired generation (la generazione connessa) e della cultura dei computer dei capelloni (pensiamo all'UNIX open source) le trovate proprio nei fuggiaschi della controcultura degli anni Settanta (Figura 1.4). Come ricorda Stewart Brand, il fondatore (anche lui hippy) del Whole Earth Catalog, `Fai la tua cosa' si traduceva facilmente in `Avvia la tua impresa' .

Ho perso il con-

1.1.

INTERNET E WWW

Figura 1.4:

I movimenti libertari portarono con sè nuovi modi di abitare e di vivere.

In alcuni casi questi stili di vita alternativi erano accompagnati da una forte componente tecnologica che si esprimeva nella autocostruzione delle nuove abitazioni:

Proposte

all'industria americana, che di fatto le guarda con scetticismo, le cupole geodetiche fanno fatica a decollare.

Vengono, però, accolte con entusiasmo dai giovani [...]

Nel 1966

a Città di Trinidad, nel Colorado, dieci ragazzi e tre ragazze, le utilizzano per realizzare una comune dal nome emblematico di Drop City. e economici [...]

I materiali usati sono semplici

Drop City diventa ben presto un modello per una generazione di ra-

gazzi che al Vietnam e al carrierismo mostra di preferire l'amicizia, il libero amore, la musica. (Prestinenza Puglisi 2013).

to delle centinaia di persone nella cerchia delle mie conoscenze che hanno lasciato le comuni per avviare, alla ne, società high tech nella Silicon Valley. Ormai è quasi un cliché: da scalzo a miliardario , proprio come Steve Jobs. (Kelly 2011). Non fu un caso dunque che proprio l'autore del Catalog, Stewart Brand (con Steven Levy) fosse tra gli organizzatori delle prima Hacker Conference nel 1984 (Brand fu anche co-fondatore di The WELL, The Whole Earth 'Lectronic Link, una delle comunità virtuali più antiche e numerose). Proprio alla prima Hacker Conference del 1984 Burrel smith, l'hacker che stava dietro il computer Apple della Macintosh, de nì il termine nel modo seguente: Gli hacker possono fare qualsiasi cosa e restare sempre hacker.

Per essere un hacker, l'alta tecnologia non è assolutamente neces-

saria. Penso piuttosto che l'essere hacker abbia a che fare con l'abilità e la dedizione per ciò che si fa . Nella guida Come diventare hacker, Raymond osserva che ci sono persone che applicano l'attitudine hacker a cose diverse dal software, come l'elettronica e la musica, in realtà la si può trovare ai più alti livelli di qualsiasi scienza o arte (Himanen 2001, p. 17). Proprio perché

CAPITOLO 1.

OPEN SOURCE

a forte connotazione culturale e politica l'attitudine hacker Ă¨, secondo la loro stessa comunitĂ , portatrice di un'etica propria, l'etica hacker. Secondo il

5 Jargon File , un documento online che comprende e spiega il lessico hacker, l'etica hacker si basa sulla credenza che la condivisione di informazioni Ă¨ un bene fortemente positivo ed Ă¨ un dovere etico degli hacker condividere la loro esperienza scrivendo codice open-source, facilitando l'accesso alle informazioni e a risorse computazionali quando possibile . L'etica hacker non Ă¨ esattamente oggetto di questa tesi, e maggiori informazioni possono essere trovate nel libro di Pekka Himanen L'etica Hacker del 2001(che Ă¨ anche la fonte principale di questo paragrafo). CiĂ˛ che perĂ˛ Ă¨ sicuramente interessante notare Ă¨ che il fenomeno degli hacker e dell'hacking Ă¨ un fenomeno nuovo, di cilmente inquadrabile in un'etica del lavoro di stampo capitalista come la nostra. Per meglio comprenderla si puĂ˛ risalire ai precedenti storici dell'etica hacker che sono l'accademia e l'etica scienti ca:

quando il famoso socio-

logo della scienza Robert Merton descrisse lo sviluppo dell'etica scienti ca nel Rinascimento, a ermĂ˛ che una delle sue fondamenta era il `comunismo', ovvero l'idea che la conoscenza scienti ca dovesse essere pubblica, un'idea che il Rinascimento ha fatto rivivere dall'etica accademica della prima comunitĂ scienti ca, l'Accademia di Platone, che si basava sull'idea di synusia, l'azione concertata nella quale la conoscenza veniva condivisa liberamente. (Himanen 2001, p. 45).

1.2

Dal free software all'Open Source

1.2.1 Free software Non si puo' parlare di free software senza accennare all'inventore del termine, il sico (ma piĂš conosciuto per le sue doti di hacker e informatico) Richard Stallman. Ă&#x2C6; infatti a lui che deve essere attribuito il merito di aver coniato il termine free software e di aver sviluppato gli strumenti che ne permettono lo sviluppo e l'utilizzo, come ad esempio la licenza GNU-GPL. Impiegato presso il centro di ricerca sull'Intelligenza arti ciale al MIT dal 1971 al 1984, Stallman (che si autode nisce l'ultimo hacker) si scontrĂ˛ presto con le prime licenze software protette da copyright che non permettevano all'utente nale di apportare modi che adattando il software alle proprie necessitĂ . Abituato

5 Il

Jargon File

Ă¨ un documento originariamente redatto da Raphael Finkel della

Stanford University e attualmente mantenuto da Eric S. Raymond, un esponente della cultura hacker nel mondo.

Esso Ă¨ essenzialmente un vocabolario del gergo usato da-

gli hacker e dai professionisti dell'IT, ma contiene anche de nizioni e regole di buona educazione da rispettare in rete (netiquette).

http://www.catb.org/jargon/.

L'attuale versione si trova all'indirizzo

1.2.

DAL FREE SOFTWARE ALL'OPEN SOURCE

a far parte di una comunitĂ in cui ci si scambiavano i programmi, che esisteva giĂ da molti anni. La condivisione del software non si limitava alla nostra comunitĂ ; Ă¨ una cosa vecchia quanto i computer, proprio come condividere le ricette Ă¨ antico come l'arte culinaria. Ma noi lo facevamo piĂš di chiunque altro (Stallman 2003, p. 11). Stallman abbandonĂ˛ il laboratorio del MIT non appena si rese conto che il software proprietario stava ormai permeando il suo lavoro e che non era piĂš possibile utilizzare liberamente le macchine del laboratorio. Decise cosĂŹ di intraprendere la compilazione di un nuovo sistema operativo, denominato GNU, che potesse esse totalmente libero. AttuĂ˛ ciĂ˛ attraverso la creazione di una apposita fondazione no-pro t, la Free Software Foundation (FSF), la quale aveva il compito di occuparsi dello sviluppo del software libero. Software libero, secondo l'interpretazione di Stallman, ha una particolare accezione: 'Il `software libero' Ă¨ una questione di libertĂ , non di prezzo. Per capire il concetto, bisognerebbe pensare alla `libertĂ di parola' e non alla `birra gratis' [il termine `free' in inglese signi ca sia `gratuito' che `libero', in italiano il problema non esiste]. L'espressione `software libero' si riferisce alla libertĂ dell'utente di eseguire, copiare, distribuire, studiare, cambiare e migliorare il software.

PiĂš precisamente, esso si riferisce a quattro tipi di

libertĂ per gli utenti del software: LibertĂ di eseguire il programma, per qualsiasi scopo (libertĂ 0). LibertĂ di studiare come funziona il programma e adattarlo alle proprie necessitĂ (libertĂ 1). L'accesso al codice sorgente ne Ă¨ un prerequisito. LibertĂ di ridistribuire copie in modo da aiutare il prossimo (libertĂ 2). LibertĂ di migliorare il programma e distribuirne pubblicamente i miglioramenti, in modo tale che tutta la comunitĂ ne tragga bene cio (libertĂ 3). L'accesso al codice sorgente ne Ă¨ un prerequisito (Stallman 2003, p. 59). Se si pensa che la cultura hacker, cui Stallman fa riferimento, derivava direttamente dai movimenti libertari degli anni Sessanta all'interno dei quali la componente etica e morale non Ă¨ a atto da sottovalutare, non Ă¨ un caso che la de nizione di software libero a ronti direttamente il concetto di libertĂ , declinandone gli attributi rispetto al software e ai sui usi. L'invenzione piĂš interessante di Stallman fu perĂ˛ quella del Copyleft (anche detto permesso d'autore), ovvero del regime giuridico all'interno del quale Ă¨ possibile mantenere tutte le caratteristiche del software libero e quest'ultimo sia considerato tale. CiĂ˛ avvenne principalmente attraverso lo sviluppo di una apposita licenza (la licenza GNU-GPL) atta a garantire lo status libero al software che veniva distribuito. Nel particolare il permesso d'autore [copyleft] usa le leggi sul diritto d'autore [copyright], ma le capovolge per ottenere lo scopo opposto: invece che un metodo per privatizzare il software, diventa infatti un mezzo per mantenerlo libero. Questo tipo di licenza Ă¨ l'innovazione giuridica

CAPITOLO 1.

OPEN SOURCE

piĂš importante del movimento free software. [..] La GPL richiede a chiunque modi chi il software e ne distribuisca una versione modi cata di rilasciarla sotto lo stesso tipo di licenza che ha il software originale. (Benkler 2007, p. 81). Il succo dell'idea del copyleft consiste quindi nel dare a chiunque il permesso di eseguire il programma, copiare il programma, modi care il programma e distribuirne versioni modi cate, ma senza dare il permesso di aggiungere restrizioni. In tal modo, le libertĂ essenziali che de niscono il free software sono garantite a chiunque ne abbia una copia, e diventano diritti inalienabili. PerchĂŠ un permesso d'autore sia e cace, anche le versioni modi cate devono essere libere.

(Stallman 2003, p.

22).

Il concetto di copyleft, oltre a ga-

rantire la maggior parte delle licenze di software libero e open source, Ă¨ alla base delle attuali licenze Creative Commons che governano la distribuzione dei contenuti di Wikipedia e di tanti altri servizi online. Un evento piuttosto importante caratterizzĂ˛ lo sviluppo e la di usione del software libero, e fu l'avvento di Linux nel 1991. Uno studente nlandese, Linus Torvalds, cominciĂ˛ a sviluppare un suo personale sistema operativo, denominato Linux, e ne condivise attraverso Internet il codice sorgente invitando tutti gli appassionati a provarlo sui propri calcolatori e a fornire commenti e feedback sul suo funzionamento. Ma quello che ottenne fu molto di piĂš: moltissimi sviluppatori risposero al suo invito e cominciarono a collaborare con lui per migliorare ed espandere il codice sorgente. CosĂŹ nell'arco di pochi anni, grazie al telelavoro collettivo di tutti gli appassionati guidati dallo stesso Torvalds, venne sviluppato un sistema competitivo per a dabilitĂ e sicurezza secondo modalitĂ di lavoro del tutto inconsuete che di lĂŹ a poco avrebbero cambiato il mondo dell'informatica e dei contenuti digitali. Lo sviluppo di Linux si basava (e si basa ancora oggi) sul principio che il codice sorgente (source) potesse essere condiviso liberamente tra gli interessati e, poichĂŠ era visibile a tutti e sostanzialmente aperto (open), le persone coinvolte potevano e ettuare modi che per rendere il codice piĂš robusto ed e ciente, aggiungere nuove funzionalitĂ , riparare eventuali errori e risolvere bug. In pochi anni e a costi irrisori (il costo di trasmissione di dati a carico degli utenti stessi, comunque trascurabile) era stato creato un prodotto che non solo era a dabile e robusto, ma anche concorrenziale rispetto ai sistemi operativi commerciali (sviluppati grazie a ingenti investimenti delle software house) e soprattutto in continuo sviluppo, miglioramento ed espansione. Per confermare il successo di Linux basta pensare al fatto che la maggior parte di server e supercomputer utilizzano Linux come sistema operativo al posto di altro software commerciale.

1.2.

DAL FREE SOFTWARE ALL'OPEN SOURCE

1.2.2 Open Source The hacker movement referred to by the term open-source has burst into public consciousness in the last few years due to its spectacular success in the production of reliable and robust software. Perhaps the most obvious symptom of this success is the fact that open-source software in several key areas (operating systems, server software) is the only serious alternative to the domination of the market by large corporations like Microsoft. Its paradigm of software production, collectively-created programs in a process where users are also (to di erent degrees) developers, has gone beyond the expectations of most analysts, and taken by surprise most corporate managers many of which (at corporations like IBM and SUN) are rapidly switching from proprietary standards to open systems.

(DeLanda 2001)

Nel precedente paragrafo si Ă¨ parlato principalmente di free software, mentre in questo paragrafo si a ronterĂ il tema dell'Open Source. In realtĂ i due termini, seppure di erenti, vengono spesso utilizzati con una certa ambiguitĂ per indicare la stessa cosa. Secondo Stallman Software libero (free software) e sorgente aperto (Open Source) descrivono piĂš o meno la stessa categoria di software, ma dicono cose di erenti sul software e sui valori.

Il progetto

GNU continua a usare il termine `software libero' per esprimere l'idea che la libertĂ sia importante, non solo la tecnologia. (Stallman 2003, p. 40). Se dunque free software presuppone anche delle caratteristiche etiche riguardo la produzione e la distribuzione del software, Open Source ne indica unicamente il metodo di sviluppo. L'uno non esclude automaticamente l'altro, ma non necessariamente l'uno corrisponde anche all'altro. A partire dal 1998 la comunitĂ ha cominciato a dividersi sull'uso dei due termini. Se da un lato il termine free software resiste tra i puristi del software libero, il termine Open Source ha avuto piĂš fortuna sia dal punto di vista commerciale che dal punto di vista mediatico, arrivando a essere un appellativo di successo per il software (si pensi ad esempio al sistema operativo mobile Android). Il termine

6 Il movimento hacker a cui si riferisce il termine open source ha fatto irruzione nella coscienza pubblica negli ultimi anni grazie al suo grande successo nella produzione di software a dabili e robusti. Forse il sintomo piĂš evidente di questo successo risiede nel fatto che il software open-source Ă¨ l'unica alternativa seria in molti settori chiave (sistemi operativi, server software) al predominio nel mercato di grandi aziende come Microsoft. Il suo paradigma di produzione di software, di programmi creati collettivamente in un processo in cui gli utenti sono anche (in diversa misura) gli sviluppatori, Ă¨ andato aldilĂ delle aspettative di molti analisti, e ha colto di sorpresa la maggior parte dei manager aziendali, molti dei quali infatti (in multinazionali come IBM e SUN) sono passati velocemente da standard proprietari a sistemi aperti. [traduzione italiana a cura dell'autore].

CAPITOLO 1.

OPEN SOURCE

open source software venne introdotto al posto di free software per neutralizzarne i connotati politici. Era semplicemente una forma di organizzazione della produzione di software che poteva essere piĂš e cace di quella basata sul mercato. [...] La vasta adozione dell'open source nei circuiti burocratici ed economici ha permesso al software libero di lasciare i margini del mondo informatico, conquistando il centro del dibattito sulle alternative allo stato di cose presente (Benkler 2007, p. 84). Inoltre bisogna considerare il fatto che il termine Open Source ha avuto fortuna anche in altri campi applicativi, non solo nel campo del software (come si vedrĂ nel prossimo capitolo). Come detto in precedenza, Linux Ă¨ forse il primo software open source di successo e ciĂ˛ signi ca che non solo con Linux si Ă¨ veri cata la bontĂ di un metodo di sviluppo software non tradizionale (in realtĂ , seguendo la storia degli hacker, il software Ă¨ sempre stato oggetto di mutuo scambio) e commerciale, ma si Ă¨ anche riusciti a dimostrare come il paradigma Open Source sia valido tanto quanto i metodi di sviluppo chiusi adottati dalle software house. CiĂ˛ ha contribuito ad a ermare che la passione e gli interessi personali, se opportunamente gestiti e veicolati, hanno la possibilitĂ di tenere testa a investimenti anche cospicui delle grandi software house.

Ă&#x2C6; infatti piuttosto chiaro che

l'Open Source funziona attraverso il contributo di un numero variabile di persone interessate al progetto e che, tramite un mutuo scambio di codice, pareri e suggerimenti il software viene sviluppato collettivamente e costantemente migliorato e aggiornato. CiĂ˛ che Ă¨ meno chiaro Ă¨ come e ettivamente il progetto di software open source debba essere gestito in modo che gli sforzi dei singoli utenti siano ottimizzati e costantemente rivolti allo sviluppo, evitando di ritrovarsi in una babele di programmatori in sostanziale concorrenza tra loro. Se dal punto di visto teorico il funzionamento Ă¨ piuttosto chiaro, dal punto di vista pratico alcune interessanti indicazioni ci vengono fornite da Eric S. Raymond nel suo testo La cattedrale e il bazaar. Raymond, particolarmente colpito dal successo di Linux, decise di cominciare a gestire lo sviluppo Open Source di un client mail (Fetchmail, un analogo dei contemporanei Thunderbird e Outlook) e di sperimentare alcune teorie circa lo sviluppo del software in modo aperto. Scrive infatti nell'introduzione del suo testo, riferendosi al titolo dello stesso: Linux stravolse gran parte di quel che credevo di sapere.

Per anni avevo predicato il vangelo Unix degli strumenti agili,

dei prototipi immediati e della programmazione evolutiva.

Ma ero anche

convinto che esistesse un punto critico di complessitĂ al di sopra del quale si rendesse necessario un approccio centralizzato e a priori. Credevo che il software piĂš importante (sistemi operativi e strumenti davvero ingombranti come Emacs) andasse realizzato come le cattedrali, attentamente lavorato a mano da singoli geni o piccole bande di maghi che lavoravano in splen-

1.2.

DAL FREE SOFTWARE ALL'OPEN SOURCE

dido isolamento, senza che alcuna versione beta vedesse la luce prima del momento giusto.

Rimasi non poco sorpreso dallo stile di sviluppo proprio

di Linus Torvalds di ondere le release presto e spesso, delegare ad altri tutto il possibile, essere aperti no alla promiscuitĂ . Nessuna cattedrale da costruire in silenzio e reverenza. Piuttosto, la comunitĂ Linux assomigliava a un grande e confusionario bazaar, pullulante di progetti e approcci tra loro diversi (e cacemente simbolizzati dai siti contenenti l'archivio di Linux dove apparivano materiali prodotti da chiunque).

Un bazaar dal quale soltanto

una serie di miracoli avrebbe potuto far emergere un sistema stabile e coerente. (Raymond 1998, p. 1) Il tipo di approccio a bazar Ă¨ per l'appunto l'oggetto delle sue ricerche, dalla cui sperimentazione Raymond enuncia 19 regole d'oro, che vengono messe in pratica e sperimentate attraverso lo sviluppo del sopracitato Fetchmail.

Di queste 19 regole, di seguito verranno

trascritte e brevemente commentate le principali e piĂš signi cative, indicate con il numero presente nel saggio.

1) Ogni buon lavoro software inizia dalla frenesia personale di uno sviluppatore. Lo sviluppo di nuovo software innovativo non puĂ˛ essere unicamente la voglia di risultare competitivi nel mercato, ma molto spesso Ă¨ collegato alla necessitĂ di risolvere problemi contingenti anche personali. In altre parole, la necessitĂ Ă¨ la madre di tutte le invenzioni (Berra & Meo 2001).

2) I bravi programmatori sanno cosa scrivere. I migliori sanno cosa riscrivere (e riusare). Ovvero Nulla si crea, nulla si distrugge, tutto si trasforma. Nulla si crea ex-novo nel mondo della tecnologia moderna (caratterizza da un'enorme complessitĂ intrinseca) ma molto spesso si parte da un modello preesistente con l'obiettivo di miglioralo adattandolo alle proprie necessitĂ .

6) Trattare gli utenti come co-sviluppatori Ă¨ la strada migliore per ottenere rapidi miglioramenti del codice e debugging e cace. 7) Distribuisci presto. Distribuisci spesso. E presta ascolto agli utenti. 8) Stabilita una base di beta-tester e co-sviluppatori su cientemente ampia, ogni problema verrĂ rapidamente de nito e qualcuno troverĂ la soluzione adeguata. 9) La cosa migliore, dopo l'avere buone idee, Ă¨ riconoscere quelle che arrivano dagli utenti. Qualche volta sono le migliori. Queste quattro regole costituiscono il vero nodo innovativo portato da Linus Torvalds nello sviluppo di Linux. Tale modello di collaborazione basato sull'integrazione dei ruoli degli utilizzatori e degli sviluppatori Ă¨ il primo e necessario passo per attivare un sistema aperto (o un sistema bazaar) in cui la partecipazione di piĂš attori sia veramente un valore aggiunto fondamentale.

19) Stabilito che il coordinatore dello sviluppo abbia a disposizione un medium almeno altrettanto a dabile di Internet, e che sappia come svolgere

CAPITOLO 1.

OPEN SOURCE

il ruolo di leader senza costrizione, molte teste funzionano inevitabilmente meglio di una sola. In questo caso il commento piĂš e cace Ă¨ quello dato dallo stesso Raymond: Penso che il futuro del software open source apparterrĂ sempre piĂš alle persone che sanno come giocare al gioco di Linus, persone che si lasceranno alle spalle la cattedrale per entrare nel bazaar. CiĂ˛ non signi ca che non saranno piĂš importanti le visioni e l'intelligenza individuali; credo piuttosto che la punta avanzata del software open source apparterrĂ a quanti sapranno muovere da visioni e intelligenza individuali per poi ampli carle tramite l'e ettiva costruzione di comunitĂ volontarie d'interesse. E forse ciĂ˛ vale non soltanto per il futuro del software open source. Nessuno sviluppatore in `closed -source' potrĂ mai pareggiare la fucina di talenti che la comunitĂ Linux Ă¨ in grado di riunire per a rontare un problema. Sono davvero in pochi a potersi permettere di assumere le oltre duecento persone che hanno contribuito a Fetchmail! Forse alla ne la cultura dell'open source trionferĂ non perchĂŠ la cooperazione sia moralmente giusta o perchĂŠ il software `costretto' sia moralmente sbagliato (dando per scontato che si creda a quest'ultima a ermazione, cosa che nĂŠ io nĂŠ Linus facciamo), ma semplicemente perchĂŠ il mondo `closed -source' non Ă¨ in grado di vincere la corsa agli armamenti dell'evoluzione contro quelle comunitĂ open source capaci di a rontare un problema con tempi e capacitĂ superiori di diversi ordini di grandezza. (Raymond 1998, p. 13)

1.2.3 Anarchia organizzata Without global control from the top, the Linux project has achieved a ne balance between evolution and self-organization, order and disorder. Stuart Kau man argues that complex systems come to the edge of chaos through the same processes that guide Darwinian evolution, namely, natural selection. Systems must evolve for a right amount of evolvability; systems that do not nd the sweet spot simply die out. But once the system is at the edge of chaos, we are bound to see surprises. Linux, like the eye, is one such system that has come to dazzle us all.

(Kuwabara 2000)

7 Senza un controllo globale dall'alto, il progetto Linux ha raggiunto un buon equilibrio tra evoluzione e auto-organizzazione, tra ordine e disordine.

Stuart Kau man sostiene

che sistemi complessi arrivano sull'orlo del caos attraverso gli stessi processi che guidano l'evoluzione darwiniana, ovvero attraverso la selezione naturale. I sistemi devono evolversi no a un certo livello di sviluppo; i sistemi che non trovano il punto giusto semplicemente muoiono. Ma Ă¨ quando il sistema Ă¨ sull'orlo del caos che abbiamo delle sorprese. Linux, come l'occhio, Ă¨ uno di quei sistemi che Ă¨ arrivato a stupire tutti noi. [traduzione italiana a cura dell'autore].

1.2.

DAL FREE SOFTWARE ALL'OPEN SOURCE

Lo spirito Open Source postula una sorta di cyberanarchia che Ă¨ deregolata, come si conviene a tutte le forme di anarchia, ma anche ispirata a ideali di collaborazione, solidarietĂ e disinteresse.

Contro

ogni attesa, e malgrado enormi gli enormi interessi economici in gioco, Ă¨ in questo spirito libertario che dobbiamo alcune delle piĂš brillanti invenzioni nel campo delle nuove tecnologie, dal protocollo http al sistema operativo Linux.

(Carpo 2009b)

Molti autori si sono concentrati sul funzionamento di Linux e sul suo tipo di organizzazione, la quale, al pari delle tipologie organizzative tradizionali presenti nell'economia aziendale, Ă¨ in grado di produrre risultati concorrenziali, sebbene non agisca all'interno delle stesse dinamiche di mercato dei suoi concorrenti. Difatti secondo le nostre normali assunzioni sui progetti volontari e sui processi a produzione decentrata che non hanno una gestione manageriale, questo modello non dovrebbe avere successo. Ma l'ha avuto e continua ad averlo. (Benkler 2007, p.

83).

Questo sistema di produzione

sociale orizzontale Ă¨ stato studiato e a rontato da diversi autori di cui si proverĂ ad esporre brevemente le tesi. Tuttavia si ritiene che tutte le ipotesi presentate siano valide poichĂŠ sono proposte da persone con formazione e interessi diversi, le quali leggono l'Open Source dal punto di vista della loro disciplina e danno letture di erenti ma non per questo incompatibili. Meo parla di una sorta di anarchia organizzata o di giungla, rifacendosi a studi di un gruppo di ricercatori statunitensi e norvegesi dell'universitĂ di Bergen, sostenendo la funzionalitĂ del disordine.

Per certi versi infatti il

sistema organizzativo di Linux presenta delle analogie con le teorizzazioni dell'organizzazione come giungla o come anarchia organizzata, nel senso che spesso sono i problemi, contrariamente alla logica tradizionale del problem solving, che vanno in cerca delle soluzioni (Berra & Meo 2001, p.

117).

Kuwabara si concentra invece sulla complessitĂ intrinseca del sistema Linux e su come l'accettazione e non la riduzione della complessitĂ abbia portato ad avere buoni risultati: In short, it is psychologically appealing to view aggregate phenomena in terms of simple universal laws of nature, but such a point of view neglects the true complexity of reality.

The case of Linux

suggests, instead, that aggregate behaviors are better understood as emergent properties - properties that emerge out of micro-level interactions among constituents - than as qualities intrinsic to the system and independent of its constituent parts. Moreover, systems that allow open and active interaction can be more adaptive and more dynamic than closed systems that restrict their constituents. In the case of Linux, nothing in its architectural design was particularly innovative or revolutionary. [...] What set Linux apart from other operating systems in the level of quality and performance, Raymond

CAPITOLO 1.

OPEN SOURCE

submits, is not anything inherent in the original architecture, but the open and evolutionary development.

(Kuwabara 2000).

Benkler, parlando di organizzazione orizzontale, si so erma sulle tre caratteristiche che la contraddistinguono. In primis la presenza e la di usione dei personal computer e altri device ( primo, il macchinario sico per partecipare alla produzione di informazione e cultura Ă¨ distribuito in modo praticamente universale tra la popolazione delle economie avanzate ) che attraverso Internet sono collegati in rete e permettono non solo di produrre, ma anche di condividere ciĂ˛ che viene prodotto a costi trascurabili. In seguito c'Ă¨ la questione legata alla materia prima che, di erentemente dalla produzione tradizionale degli ultimi secoli, non si basa sul capitale privato: Secondo, le materie prime dell'economia dell'informazione, diversamente da quelle dell'economia industriale, sono beni pubblici: l'informazione, la conoscenza e la cultura esistenti . E in ne la possibilitĂ di partecipazione da parte degli utenti favorita dalla capacitĂ dell'organizzazione di assorbire contributi di grana ne, che richiedono minori sforzi in termini di tempo e risorse: Terzo, architetture tecnologiche, modelli organizzative dinamiche sociali di scambio e produzione di informazione su internet si sono sviluppati in modo da permettere di strutturare la soluzione dei problemi in forma altamente modulare. (Benkler 2007, p. 134). In ogni caso il sistema organizzativo che sta alla base dell'Open Source puĂ˛ essere considerato alla stregua di una learning organization, ovvero una struttura che facilita l'apprendimento dei suoi membri ed Ă¨ in un perenne stato di trasformazione o evoluzione (Senge 1992).

1.2.4 Reputazione e collaborazione Le competenze individuali diventano quindi il nucleo economico della produzione di cultura e informazione, che ha la prioritĂ sulla capa-

8 In breve, Ă¨ psicologicamente interessante per vedere i fenomeni di aggregazione in termini di semplici leggi universali della natura, ma un tale punto di vista omette la vera complessitĂ della realtĂ . Il caso di Linux suggerisce invece che i comportamenti di aggregazione siano meglio comprensibili se considerate come proprietĂ emergenti proprietĂ che emergono da interazioni di micro livello tra i costituenti piuttosto che come qualitĂ intrinseche al sistema e indipendenti dalle sue parti costituenti. In aggiunta a ciĂ˛, i sistemi che permettono un'interazione aperta e attiva possono adattarsi meglio ed essere piĂš dinamici rispetto ai sistemi chiusi, che invece limitano le loro parti costituenti. Nel caso di Linux, nulla nel suo progetto architettonico Ă¨ stato particolarmente innovativo o rivoluzionario. [. . . ] Raymond sostiene che cosa ha di erenziato Linux rispetto agli altri sistemi operativi, in termini di qualitĂ e performance, non ha a che vedere con l'architettura originale ma dipende dal suo sviluppo aperto e in continua evoluzione. [traduzione italiana a cura dell'autore].

1.2.

DAL FREE SOFTWARE ALL'OPEN SOURCE

citĂ di raccogliere capitale nanziario. Parte di questa competenza Ă¨ scambiata sui mercati come lavoro creativo, e continuerĂ ad esserlo. Tuttavia, grazie alla sua liberazione dai ceppi del capitale sico, le persone creative possono prendere parte a una gamma piĂš ampia di pratiche di produzione di cultura e informazione rispetto al tempo in cui, oltre a creativitĂ , esperienza, sapere e tempo, per produrre informazione c'era bisogno di avere milioni di dollari. [...] Nell'economia sica queste relazioni erano relegate quasi completamente al di fuori del sistema di produzione, mentre l'economia dell'informazione in rete reca con sĂŠ la promessa di proiettare la ricchezza della vita sociale al centro dell'economia e della produzione.

(Benkler 2007, p. 66)

La proprietĂ che emerge da un sistema di menti umane in comunicazione fra loro Ă¨ il fatto che esse realizzano opere per il reciproco godimento e per vincere il loro penoso senso di solitudine.

(Moglen 1999)

Una delle domande principali che ci si pone nel momento in cui si a ronta il tema dell'Open Source Ă¨ il tentativo di capire quali siano le motivazioni che spingono le persone a parteciparvi. Infatt non si Ă¨ all'interno della normale produzione industriale, dove il lavoro viene normalmente remunerato, ma ci si trova in un sistema di produzione sociale, dove la remunerazione non ha luogo, o perlomeno non ha luogo come tradizionale transizione di denaro tra datore di lavoro e lavoratore. Molti autori hanno dato la loro risposta e molti sono i contributi scienti ci che possono essere presi in esame. Di questi, si farĂ un breve accenno a quelli piĂš signi cativi e interessanti per il prosieguo della tesi, consci che questa breve trattazione possa non essere considerata esaustiva. La prima risposta si rifĂ alla teoria del dono, ovvero la teoria secondo cui ciĂ˛ che dĂ origine al software libero Ă¨ un atto di liberalitĂ da parte di chi mette il prodotto in rete (il donatore), a cui corrisponde una libertĂ di risposta da parte di chi riceve. I tre obblighi del dare, ricevere e restituire impliciti nel dono non sono garantiti formalmente, ma sono obblighi morali che mantengono un contenuto di libertĂ (Berra & Meo 2001). Altra risposta possibile Ă¨ quella basata sul fattore della reputazione, ovvero che la partecipazione a questo tipo di esperienze in maniera produttiva porti a un riconoscimento personale all'interno della comunitĂ : the norm of cooperation is shaped by reputation game because people compete for peer

recognition. (Kuwabara 2000).

9 La regola della cooperazione si basa sul gioco della reputazione perchĂŠ le persone competono per il riconoscimento tra pari. [traduzione italiana a cura dell'autore].

CAPITOLO 1.

OPEN SOURCE

Oltre a queste due risposte ve ne Ă¨ una terza, forse piĂš semplicistica, ma per certi versi anche piĂš e cace. Secondo Eben Moglen la risposta Ă¨ nella natura umana. Ă&#x2C6; come chiedersi perchĂŠ Figaro canta, perchĂŠ Mozart compose la musica che lui canta, e perchĂŠ tutti noi parliamo: perchĂŠ possiamo. Homo ludens, stringi la mano all' Homo Faber. La condizione sociale di interconnessione globale che chiamiamo Internet rende possibile a tutti noi di essere creativi in modi nuovi e mai sognati. A meno che non lasciamo che la `proprietĂ ' interferisca. (Moglen 1999). Ed Ă¨ questa forse la risposta piĂš esaustiva. Non si spiegherebbe sennĂ˛ il lavoro enorme svolto da tutti i contributori di Wikipedia (la riposta del dono Ă¨ accettabile, ma prevede la proprietĂ di ciĂ˛ che si dona e soprattutto che questa passi a qualcun altro, quando nella realtĂ la proprietĂ dell'informazione non Ă¨ uno dei fattori in gioco essendo essa libera); nĂŠ tantomeno quello svolto dai redattori della documentazione che accompagna il software (che fondamentalmente non viene considerata una attivitĂ di rilievo, anche se fatta a regola d'arte, non comporta infatti particolare considerazione da parte dei programmatori e quindi non porta a ottenere alcun tipo di reputazione). La voglia di creare e comunicare, che si combina con l'esperienza sociale e culturale che si esplicita nel Web, ha come e etto quello di spingere ognuno di noi a parlare di ciĂ˛ che pensiamo possa interessare anche altri. E questo va esattamente contro il sistema di produzione di massa dell'informazione poichĂŠ al posto di poche voci (o emettitori di informazioni) si creano e si creeranno tutta una serie di mercati di nicchia all'interno dei quali vigeranno dei sistemi di produzione non commerciali. Sempre piĂš informazione verrĂ prodotta da sempre piĂš attori a costi sempre piĂš marginali. Ci troveremo dunque in una situazione nella quale i comportamenti sociali che tradizionalmente erano legati ai margini dell'economia capitalista sono diventati elementi fondamentali delle economie avanzate. I comportamenti non commerciali stanno diventando fattori determinanti per la la produzione dell'ambiente informazionale e culturale. (Benkler 2007).

1.2.5 ModularitĂ e ricombinazione Nella ricombinazione di tutta l'informazione e di tutta la comunicazione esistente sulla base di scopi speci ci decisi in tempo reale da ciascun utente/produttore dell'ipertesto. La ricombinazione Ă¨ fonte di innovazione, in particolare se i prodotti che genera diventano a loro volta sostegni per una ulteriore interazione, in una spirale di informazioni sempre piĂš signi cative. La generazione di nuove conoscenze richiederĂ sempre l'applicazione di una teoria dell'informazione ricombinante. Le possibilitĂ di sperimentare con questa caratteristica che ha l'informazione da una molteplicitĂ di fonti ampliano notevolmente sia il campo

1.2.

DAL FREE SOFTWARE ALL'OPEN SOURCE

della conoscenza, sia le connessioni che possono essere fatte tra ambiti di erenti - proprio come la fonte di innovazione della conoscenza veniva descritta da Kuhn nella teoria delle innovazioni scienti che.

(Castells 2001)

Ă&#x2C6; molto interessante osservare come i processi di produzione sociale che si sono sviluppati grazie ad internet, e che Benkler descrive cosĂŹ bene nel suo libro La ricchezza della rete, siano profondamente collegati al tipo di infrastruttura che ne permette la di usione e la crescita. Non a caso infatti la produzione sociale, per essere e cace, si basa su due concetti fondamentali: il primo Ă¨ la modularitĂ , il secondo Ă¨ la ricombinazione.Vediamo meglio di cosa si tratta. Nel paragrafo precedente si Ă¨ visto come uno dei fattori che garantiscono l'e cacia della produzione sociale sia la possibilitĂ di strutturare la soluzione dei problemi in forma altamente modulare. CiĂ˛ signi ca che la riduzione a entitĂ modulari di qualsivoglia problema ne favorisce una risoluzione di tipo orizzontale poichĂŠ ogni attore puĂ˛ scegliere il modulo su cui operare in maniera indipendente, conscio del fatto che il suo tassello andrĂ a comporre un quadro complessivo risolutivo (frutto di altri tasselli che sono frutto a loro volta del lavoro di altri). CiĂ˛ permette alcuni vantaggi: da un lato l'utente Ă¨ libero di scegliere secondo il suo gusto personale o secondo la sua esperienza o le sue capacitĂ , dall'altro puĂ˛ scegliere secondo la sua disponibilitĂ di tempo e voglia di partecipare. La `modularitĂ ' Ă¨ la proprietĂ che descrive il grado con cui un progetto puĂ˛ essere spezzettato in componenti piĂš piccole, o moduli, che possono essere prodotti indipendentemente e poi riassemblati in modo coerente.

Se i moduli sono indipendenti, i singoli collaboratori sono messi

nella condizione di scegliere come e quando contribuire, in maniera indipendente l'uno dall'altro.

In questo modo vengono massimizzate l'autonomia

e la essibilitĂ nel de nire natura, grandezza e durata della partecipazione al progetto. (Benkler 2007, p.128). Volendo fare un piccolo esempio si pensi all'utente di Wikipedia interessato a contribuire: egli potrĂ scegliere quale argomento approfondire, su quale speci ca voce intervenire, quante voci modi care, creare o implementare, il tutto seguendo le sue inclinazioni culturali, a partire dalla lingua di interesse no al piĂš piccolo particolare. PotrĂ anche solo modi care o inserire la data precisa di un evento storico, potrĂ contribuire con un centinaio di modi che al giorno o farne una al mese, sempre secondo la sua disponibilitĂ . La sostanziale modularitĂ Ă¨ anche alla base della commutazione di pacchetto che permette alle informazioni di essere scambiate tra un nodo e l'altro. Attraverso il protocollo TCP/Ip l'informazione di partenza viene suddivisa in tante parti uguali (i pacchetti per l'appunto) e ad ogni pacchetto viene dato l'indirizzo del nodo di arrivo

CAPITOLO 1.

OPEN SOURCE

(l'indirizzo IP). I pacchetti viaggiano separatamente, sfruttando tutto il potenziale del network, spostandosi da un nodo all'altro nché non raggiungono il nodo di arrivo. In corrispondenza del nodo di arrivo i pacchetti vengono ricompattati e l'informazione viene trasmessa al destinatario. Ciò permette di non intasare le linee dirette tra un nodo e l'altro ma di sfruttare tutte le linee momentaneamente inattive per far passare i vari pacchetti. Si sfrutta dunque una proprietà intrinseca dell'architettura di Internet (la struttura a network) massimizzandone i vantaggi. Il secondo fondamento è la ricombinazione. Anch'esso è contenuto nello stessa infrastruttura: ogni volta che inviamo una e-mail, gli elaborati algoritmi invisibili del server decidono il percorso che il nostro messaggio seguirà attraverso la rete globale allo scopo di arrivare con il minimo intralcio e la massima velocità. La scelta quantistica forse non svolge alcun ruolo in queste decisioni; piuttosto, a in uenzarle sono miliardi di fattori deterministici che interagiscono tra loro.

Poiché districare questi fattori è un problema

insolvibile, queste scelte sono di fatto decisioni dettate dalla libera volontà della rete, e Internet ne prende miliardi ogni giorno.

(Kelly 2011, p.319).

Per Internet ciò signi ca ricombinare in continuazione in nite possibilità di percorsi per districarsi nella rete e far arrivare la nostra mail ai nostri colleghi, costruendo continuamente soluzioni nuove basandosi però su soluzioni già utilizzate in precedenza. Invece per quanto riguarda la produzione sociale, questo tipo di fenomeno è forse più visibile nel mondo del software open source e delle librerie che vengono usate per svilupparlo. Le librerie sono degli archivi di funzioni scritte in linguaggio informatico che vengono utilizzate per sviluppare software o ulteriori altre funzioni. La ricombinazione continua di parti di codice informatico scritto da altri e utilizzato per i propri scopi e in ne condiviso e ulteriormente sviluppato, è esattamente quello che viene inteso per ricombinazione: tutti i risultati della produzione sociale vengono continuamente ricombinati tra di loro per creare nuovi prodotti che vengono ricombinati a loro volta da altri utenti, e così via. Si noti come in realtà la modularità e la ricombinazione siano anche alla base dello sviluppo biologico della vita (la ricombinazione dei lamenti di DNA durante la riproduzione e la composizione dei lamenti stessi, composte da proteine, composte a loro volta da amminoacidi ricombinati insieme). Questi due fattori, uniti al sostanziale progresso dell'interfaccia uomo macchina e degli strumenti di interazione tra di essi, de niscono la logica tecnica stessa degli strumenti digitali che suggerisce degli usi aperti, collaborativi e partecipativi, e questo non solo nel campo del software.

Capitolo 2 Open Design 2.1

Dal bit all'atomo

2.1.1 Non solo software La terza novitĂ , che per gli osservatori Ă¨ forse la piĂš radicale, piĂš nuova e piĂš di cile da comprendere, Ă¨ l'a ermarsi di grandi progetti cooperativi su larga scala dediti alla produzione orizzontale di informazione, conoscenza e cultura. Essi sono esempli cati dall'emergere del free software e del software open source. Ci stiamo accorgendo che questo modello non vale solo per il cuore delle nostre piattaforme software, ma si sta espandendo in tutti i settori dell'informazione e della produzione culturale, dalla produzione peer-to-peer di enciclopedie, alle news e agli editoriali no all'intrattenimento immersivo.

(Benkler 2007)

Se l'Open Source Ă¨ un modello che ha avuto particolare successo nel mondo del software, Ă¨ anche vero che il suo modello organizzativo orizzontale ha avuto particolare successo anche in altri campi: dalla creazione di contenuti digitali no ad arrivare a oggetti sici. Uno degli esempi piĂš fulgidi di questo approccio di produzione sociale peer-to-peer (tra pari, ossia una gerarchia orizzontale e non verticale) Ă¨ sicuramente Wikipedia. Quest'ultima nasce nel 2001 sulla scorta di Nupedia, un esperimento di enciclopedia online di stampo tradizionale ma con accesso libero che si rivelĂ˛ non del tutto riuscito. Il fondatore, Jimmy Wales, decise dunque di caricare le voci esistenti di Nupedia su una nuova piattaforma, utilizzando uno strumento in circolazione al tempo, il wiki, e chiamĂ˛ il nuovo progetto Wikipedia. Il passaggio da un modello chiuso a uno aperto e peer-produced si rivelĂ˛ subito di grande successo. Il sito ha infatti avuto una crescita fortissima sia nel numero di collaboratori attivi sia nel numero di voci, e da una fase iniziale in cui i contenuti erano

CAPITOLO 2.

OPEN DESIGN

disponibili unicamente in inglese si Ă¨ passati all'attuale situazione in cui la piattaforma presenta contenuti scritti in 280 lingue diverse. Il funzionamento di Wikipedia e il suo successo possono essere spiegati attraverso tre elementi chiave: l'utilizzo del wiki, le regole di redazione e il punto di vista neutrale come obiettivo e, in ne, il rilascio dei suoi contenuti con licenza Creative Commons. Il wiki (dall'hawaiano veloce) Ă¨ un software che permette a utenti diversi (che non si conoscono tra di loro e che sono liberi di nascondere la loro identitĂ attraverso dei nickname) di editare una pagina web e fare in modo non solo che la modi ca venga eseguita, ma che di questa modi ca venga lasciata una traccia (conservando tutte le versioni) e che si possa tenere memoria della varie versioni, lasciando la possibilitĂ agli utenti di ritornare a una versione precedente o e ettuare grandi o piccole modi che. Il suo software e il suo database rendono trasparenti tutte le operazioni di modi ca o aggiunta di voci.

Il wiki non Ă¨ solo un software di testo, ma integra anche alcune

opzioni che ne garantiscono il funzionamento al ne di realizzare documenti di prodotti in maniera collaborativa. Il punto di vista neutrale permette a un gran numero di utenti di avvicinarcisi. Non avendo come ne l'obiettivitĂ (quindi un punto di vista comune e univoco) il punto di vista neutrale (ovvero la volontĂ di presentare tutti i punti di vista) permette a ogni tipo di utente di presentare (argomentandolo) il proprio punto di vista, di modo che la pagina in questione sia il piĂš possibile completa.

Inoltre l'enciclopedia, per sua stessa natura, permette

la creazione di sotto gruppi di discussione e contribuzione a seconda degli argomenti che vengono trattati, aumentando cosĂŹ la possibilitĂ di ottenere utenti (non Ă¨ unicamente aperta a scienziati e storici, ma si rivolge anche ad appassionati di sport, cinema, animali, cittadini che vogliono contribuire raccontando la storia del proprio paese di origine, etc.). In ne la licenza (inizialmente una licenza GPL adattata ai testi scritti, ora una licenza Creative Common Attribuzione - Condividi allo stesso modo) applica gli stessi principi che il copyleft applica al software: Ă¨ possibile utilizzare i contenuti per i propri scopi ma i risultati, se condivisi, devono essere condivisi allo steso modo. CiĂ˛ ha permesso nel giro di pochi anni di superare abbondantemente il numero di voci della piĂš famosa Enciclopedia Britannica e di poter rivaleggiare in termini di a dabilitĂ e rilevanza (Figura 2.1). Wikipedia Ă¨ dunque forse l'esempio migliore e onnicomprensivo per descrivere con e cacia il ruolo che la produzione sociale di tipo orizzontale e la distribuzione libera dei suoi risultati puĂ˛ ricoprire nell'economia dell'informazione di rete.

Tutta-

via non Ă¨ l'unico esempio disponibile di piattaforma all'interno della quale sia possibile produrre informazione in maniera orizzontale ottenendo anche

2.1.

DAL BIT ALL'ATOMO

Figura 2.1: Il gra co illustra l'andamento del numero di collaboratori di Wikipedia nel tempo in base al numero di articoli scritti o modi cati (fonte:http://stats.wikimedia.

org/EN/ReportCardTopWikis.htm).

degli ottimi prodotti. Esempi come BIOS , che introducono l'Open Source

nel mondo delle biotecnologie, oppure come Free Beer , che si occupa sostanzialmente di distribuire una ricetta per la birra home brewed secondo la loso a dell'Open Source, sono soltanto alcune delle iniziative che dimostrano quanto l'openness sia ormai realtà assimilata dalla produzione e gestione di informazione nella nostra società. Quello che ancora è oggetto di ricerca e speculazione scienti ca è il modo attraverso cui il frutto di processi aperti e orizzontali possa essere trasferito dal mondo digitale alla realtà sica, ovvero come l'informazione aperta possa valicare la soglia del virtuale per prendere forma nel mondo materiale, mantenendo in questo processo realizzativo la sua componente `open'.

Se nel mondo industriale il passaggio

da bit (pura informazione) ad atomo (pura materia) è stato espletato dalle macchine a controllo numerico, vedremo nei prossimi paragra come anche la produzione sociale stia sviluppando i suoi processi produttivi basandosi sull'organizzazione orizzontale e aperta piuttosto che su modelli verticali o a piramide.

2.1.2 Dal bit all'atomo If the past 10 years have been about discovering post-institutional social models on the Web, then the next 10 years will be about applying them to the real world. [...] Hardware is becoming much more like software, as MIT professor Eric von Hippel puts it. That's not just because there's so much software in hardware these days, with products

1 http://www.bios.net/daisy/bios/home.html 2 http://freebeer.org/

CAPITOLO 2.

OPEN DESIGN

becoming little more than intellectual property wrapped in commodity materials, whether it's the code that drives the o -the-shelf chips in gadgets or the 3-D design les that drive manufacturing.

It's al-

so because of the availability of common platforms, easy-to-use tools, Web-based collaboration, and Internet distribution.

(Anderson 2010a)

Il passaggio da bit ad atomo non Ă¨ una questione che si pone oggi per la prima volta, ma giĂ a partire dal secondo dopoguerra l'industria (principalmente quella aeronautica legata all'US Air Force) comincia a sviluppare sistemi in grado di integrare degli elaboratori elettronici alla gestione delle lavorazioni industriali, sviluppando la tecnologia del controllo numerico (NC, Numerical Control, che diventa, dopo l'avvento massiccio del computer, CNC, Computer Numerical Control).

Da lĂŹ in poi Ă¨ un susseguirsi di

innovazioni che portano all'attuale situazione di produzione industriale, in cui la robotica e le macchine a controllo numerico sono ormai ampiamente di use. CiĂ˛ ha portato a due e etti principali: il primo Ă¨ quello di passare dalla mass-production alla mass-customization, ovvero la possibilitĂ di realizzare a costi risibili varianti continue dello stesso oggetto, passando da una produzione di massa tendenzialmente standardizzata a una produzione piĂš varia ed eterogenea, che puĂ˛ essere de nita non-standard (Cache 2011). Il secondo aspetto, in parte legato al primo, Ă¨ la di usione di tali tecnologie in molti altri ambiti non strettamente legati alla esclusiva produzione meccanica orientata al settore industriale, ma inerenti ad altri campi della produzione, come ad esempio la produzione edilizia. Se questo tipo di approccio Ă¨ ormai una realtĂ nella produzione della gran parte dei prodotti di oggi, Ă¨ opportuno segnalare che la fabbricazione digitale non Ă¨ solo al servizio delle grandi aziende ma ha cominciato a essere presente anche nella produzione sociale.

2.1.3 Fab Le arti liberali avevano tra i loro obiettivi quello di liberare e ra orzare l'individuo attraverso il dominio dei mezzi di espressione. I nuovi

3 Se negli ultimi dieci anni si Ă¨ cercato di scoprire dei modelli sociali post-istituzionali sul Web, nei prossimi dieci si cercherĂ di applicarli al mondo reale.[...] L' hardware sta diventando sempre piĂš come il software , ha a ermato il professore del MIT Eric von Hippel. CiĂ˛ accade non solo perchĂ¨ ormai c'Ă¨ molto del software nell'hardware, con prodotti che ormai sono diventati proprietĂ intellettuali con sembianze di prodotti commerciali, sia per il codice che trasforma stock di chips in gadgets o per i les di disegno 3D che guidano la produzione. Ma ciĂ˛ Ă¨ dovuto anche alla disponibilitĂ di piattaforme comuni, strumenti facili da usare e basati sulla collaborazione via Web, e alla di usione di Internet. [traduzione italiana a cura dell'autore].

2.1.

DAL BIT ALL'ATOMO

mezzi di espressione per la fabbricazione personale consentono lo sviluppo delle potenzialitĂ tecnologiche, portando quindi a una liberazione economica, intellettuale, e persino a una sorta di liberazione personale. Ritengo che il luogo migliore sul quale si puĂ˛ leggere il futuro della fabbricazione sia sui volti di una nuova generazione che grazie ai fab lab sta guadagnando l'accesso a versioni prototipizzate di queste risorse.

(Gershenfeld 2005)

Il fatto che la produzione a controllo numerico abbia permeato anche il processo di produzione peer-to-peer, non modi candone i connotati ma anzi implementandone gli esiti, Ă¨ un fenomeno dovuto a diversi fattori.

primo Ă¨ che si Ă¨ trovato un modo per permettere che la produzione sociale di informazione possa avere una sua traduzione nel mondo materiale: tale passo fondamentale Ă¨ stato compiuto grazie allo sviluppo e alla di usione dei FabLab. Il secondo fattore Ă¨ la sostanziale creazione di macchine CNC a basso costo, frutto non della produzione industriale ma della produzione sociale, basata su hardware sviluppato e prodotto dalla comunitĂ (come ad esempio Arduino) e continuamente aggiornata e sviluppata dalla comunitĂ stessa. I FabLab sono laboratori che provide widespread access to modern means for invention. They began as an outreach project from MIT's Center for Bits and Atoms (CBA). CBA assembled millions of dollars in machines for research in digital fabrication, ultimately aiming at developing programmable molecular assemblers that will be able to make almost anything. Fab labs fall between these extremes, comprising roughly fty thousand dollars in equipment and materials that can be used today to do what will be possible with tomorrow's personal fabricators. Fab labs have spread from inner-city Boston to rural India, from South Africa to the North of Norway. Activities in fab labs range from technological empowerment to peer-to-peer project-based technical training to local problem-solving to small-scale high-tech business incubation to grass-roots research. Projects being developed and produced in fab labs include solar and wind-powered turbines, thin-client computers and wireless data networks, analytical instrumentation for agriculture and healthcare, custom housing, and rapid-prototyping of rapid-prototyping ma-

chines. . Sviluppati all'interno del CBA del MIT di Boston (Center for Bit and Atoms diretto da Neil Gershenfeld) i fablab non o rono unicamente una

4 consentono largo accesso a moderni strumenti per nuove invenzioni. Sono inizati come un'estensione del progetto dal Center for Bits and Atoms (CBA) del MIT. CBA ha messo insieme milioni di dollari in macchine per la ricerca nella fabbricazione digitale, con lo scopo nale di sviluppare compilatori molecolari programmabili in grado di fare piĂš o meno qualsiasi cosa. I Fab lab rientrano tra questi due estremi, comprendono circa cinquanta mila dollari in attrezzatura e materiali che possono essre usati oggi per fare ciĂ˛ che

CAPITOLO 2.

OPEN DESIGN

dotazione di macchinari tecnologicamente avanzati, ma propongono sopratutto un modello organizzativo basato sulla possibilitĂ di uso delle macchine e sullo scambio reciproco di esperienze e informazioni piuttosto che sul tradizionale scambio economico.

I FabLab danno la possibilitĂ di accedere a

macchinari decisamente avanzati (e normalmente non di uso personale come potrebbe essere un trapano o una sega) a un gruppo piuttosto vario di utenti, favorendo un utilizzo collettivo dei macchinari stessi. Nella realtĂ i FabLab non sono gli unici a o rire questo servizio: i TechShop

negli Stati

Uniti o rono all'incirca lo stesso tipo di servizio, ma a pagamento, relegando la propria esperienza produttiva da collettiva a personale. Sono inoltre

disponibili servizi a pagamento distribuiti come ad esempio Ponoko , Razor-

lab , Formulor

e Vectorealism , i quali o rono gli stessi servizi di un fablab

a prezzi comunque accessibili. L'altro aspetto da prendere in considerazione Ă¨ lo sviluppo di macchinari a basso costo frutto principalmente della produzione sociale. Questo tipo di macchinari hanno costi piuttosto contenuti e possono tranquillamente competere con prodotti industriali. Se pensiamo

alle stampanti in 3d come MakerBot

o RipRap

e alla fresa CNC Mantis

ci accorgiamo che grazie alla condivisione di informazione, all'uso di prodotti frutto della produzione sociale (hardware open source principalmente) si stanno di ondendo sempre di piĂš macchinari a controllo numerico a basso costo, accessibili a molti o comunque presenti nei FabLab, che permettono di produrre oggetti secondo il proprio gusto e le proprie necessitĂ . Questa dotazione tecnologica di usa ha permesso lo sviluppo di nuovi sistemi di ideazione e produzione degli oggetti, sistemi che possono essere riassunti nell'accezione di open design.

sarĂ possibile fare con i personali costruttori di domani. I Fab lab si sono di usi dal centro di Boston alla rurale India, dal Sud Africa al nord della Norvegia.

Le attivitĂ nei Fab

lab spaziano dal potenziamento tecnologico tra pari basato su progetti di formazione, a problem-solving di scala locale alla piccola azienda high-tech che fa da incubatrice a ricerche appena iniziate. I progetti in sviluppo e prodotti nei fab lab includono turbine solari ed eoliche, thin-client computer e reti di dati wireless, strumenti analitici per l'agricoltura e l'assistenza sanitaria, custom housing e macchine di prototipazione rapida. Tratto da:

http://fab.cba.mit.edu/about/faq/ [traduzione italiana 5 http://www.techshop.ws/ 6 https://www.ponoko.com/ 7 http://www.razorlab.co.uk/ 8 http://www.formulor.de/ 9 http://www.vectorealism.com/ 10 http://www.makerbot.com/ 11 http://reprap.org/ 12 http://makeyourbot.wikidot.com/mantis9-1

a cura dell'autore]

2.1.

DAL BIT ALL'ATOMO

2.1.4 Open Design The value proposition and thrust of open de sign is `distributed manufacturing' processes that emphasize the use-related capabilities of openness.

The prime actors of open design are consumers.

Althou-

gh designers undoubtedly play a pivotal role in fostering open design by producing and sharing suitable design blueprints, ultimately the consumers who engage in distributed manufacturing are the core players and raison d'être of open design.

(Avital 2011)

L'open design entra nel dibattito legato ai contenuti aperti a partire dal 1999 ad opera di alcuni studenti americani di ingegneria meccanica. L'intento dei tre (Sepehr Kiani, Ryan Vallance e Samir Nayfeh) era quello di riprendere i contenuti dell'Open Source De nition (van Abel, Klaasen & Evers 2011) e applicarli al design.

Non a caso istituirono la Open Design De nition il

cui intento era quello di stabilire le condizioni necessarie a nché si potesse discutere di open design, piuttosto che darne una de nizione esatta: parafrasando l'essenza del software open source, l'open design veniva de nito come un processo progettuale all'interno del quale l'accesso, la documentazione, le modi che e i progetti derivati sono consentiti

. In pratica non venivano

de niti gli strumenti necessari a sviluppare progetti di open design, ma le caratteristiche basilari che queste iniziative avrebbero dovuto avere.

Poco

tempo prima, verso la ne del 1998, il professor Reinoud Lamberts lanciava il sito Open Design Circuits presso la TU Delft con lo scopo di sviluppare circuiti integrati nello spirito del software open source. Analogamente a quanto successe con il software libero (il manifesto GNU di Stallman data 1985, ma bisognerà aspettare no al 1991 per l'avvento di Linux) le prime de nizioni teoriche riguardo all'open design (ma anche riguardo all'Open Hardware se pensiamo all'Open Design Circuits) non ebbero un immediato ri esso sulla pratica quotidiana. Prima che ciò avvenga bisognerà aspettare alcuni anni: no al 2005 per quanto riguarda l'hardware (ovvero no alla nascita di Arduino), e no al 2006 per quanto riguarda il design, cioè quando il primo progetto di open design di un certo spessore,

13 Il valore della proposta e la spinta dell'open design consiste nei processi di produzione distribuita, i quali enfatizzano le potenzialità dell'open. Gli attori principali della progettazione dell'open design sono i consumatori. Sebbene i progettatori indubbiamente giocano un ruolo fondamentale nel promuovere l'open design producendo e condividendo progetti adeguati, sono in ultima istanza i consumatori, i quali si mettono in gioco nella produzione distribuita, i protagonisti e la ragion d'essere dell'open design. [traduzione italiana a cura dell'autore].

14 http://www.opendesign.org/odd.html

CAPITOLO 2.

OpenMoko, viene lanciato.

OPEN DESIGN

CiĂ˛ Ă¨ dovuto a vari motivi ma principalmen-

te perchĂŠ, verso la ne degli degli anni 2000, era assolutamente plausibile pensare che la direzione dello sviluppo del design e dell'hardware abbracciasse le tematiche proposte dal movimento Open Source, tuttavia non si era ancora veri cata la convergenza tecnologica che ne avrebbe favorito lo sviluppo immediato.

Figura 2.2:

Si pensi ad esempio che Wikipedia nasce nel 2001 e

La copertina di Time del 2006 segna il pieno riconoscimento dell'essenza

e del funzionamento del web 2.0

of_the_Year).

http://en.wikipedia.org/wiki/You_(Time_Person_

2.1.

DAL BIT ALL'ATOMO

che si comincia a parlare di web 2.0 solo a partire dal 2004 (con il pieno riconoscimento solo nel 2006, come testimoniato dall'ormai famosa copertina del Time, Figura 2.2) mentre i software di modellazione 3d acessibili, prin-

cipalmente Sketchup

e Blender

, vedono la luce rispettivamente nel 2000

e nel 2002 ma si a ermano al grande pubblico qualche anno piĂš tardi (nel 2006 Sketchup in seguito all'aquisizione da parte di Google e l'integrazione con Google Maps e Blender dal 2005 dopo la prima realizzazione di un lm di animazione realizzato interamente con esso:

Elephants Dream).

Detto

ciĂ˛ Ă¨ piuttosto facile notare che nonostante ci fosse un impianto teorico ef cace, non sia stato possibile mettere in pratica con successo alcuna teoria poichĂŠ non si era ancora sviluppato un ambiente tecnologico abbastanza orido che permettesse uno sviluppo adeguato. Si vedrĂ in seguito come anche per quanto riguarda l'architettura si sia sviluppato un fenomeno simile. Un passo piuttosto importante Ă¨ il lavoro dell'Open Design and Hardware

Group

a cui si deve l'attuale (e piĂš aggiornata) de nizione di Open desi-

gn: Open Design is a design artifact project whose source documentation is made publicly available so that anyone can study, modify, distribute, make, prototype and sell the artifact based on that design. The artifact's source, the design documentation from which it is made, is available in the preferred format for making modi cations to it. Ideally (but not exclusively necessary), Open Design uses readily-available components and materials, standard processes, open infrastructure, unrestricted content, and open-source design tools to maximize the ability of individuals to make and use hardware. Open Design gives people the freedom to control their technology while sharing knowledge and encouraging commerce through the open exchange of designs.

Open Design should always be considered in its political dimension,

because transparency, collaboration and release of resources are strategies that do not fully guarantee the balance and social justice by themselves. Furthermore, by making open design project we will unconver their political dimension by making everybody aware of the impact on the social, economic, and environmental dimension of everybody's life. This de nition applies to design in its broadest sense, and is not con ned to any speci c branch of design. Here design is intended as a verb: to design something (and therefore it is considered as a process) a documentation: the drawings of a design (and therefore it is a considered as a blueprint) an outcome: the design in its usable version (and therefore it is considered

15 http://www.sketchup.com/ 16 http://www.blender.org/

17 http://design.okfn.org/designdefinition/

CAPITOLO 2.

OPEN DESIGN

as an artifact) For example, Open Design could refer to a Product Design project, a Fashion Design project, a Graphic Design project, an Interior Design project, a Service Design project, an Interaction Design project, and so on.

For speci c de nition of Open Design related to a speci c branch

of design, the current de nition can be forked and extended from the Open Design De nition repository.

A Design project that includes software or

hardware can be de ned Open Design if the software is released under an OSI-approved open source license and the hardware is released under an Open Source Hardware-approved open source license.

È interessante osservare che la de nizione stessa di Open design è una de nizione aperta alle modi che e alle aggiunte, esattamente come la stringa di un software. Le varie de nizione di open design in realtà servono unicamente a delineare una tendenza, la tendenza all'open, che ha delle peculiarità ovviamente

18 L'Open Design è un progetto di design di oggetti la cui documentazione d'origine è resa disponibile pubblicamente così che chiunque può studiare, modi care, distribuire, costruire, fare un prototipo e vendere l'oggetto su cui è basato quel progetto. L'origine dell'oggetto, cioè la documentazione del progetto con cui è stato realizzato, è disponibile, nel formato che si preferisce, per fare delle modi che. Idealmente (ma non necessariamente) l'Open Design utilizza componenti e materiali facilmente reperibili, processi standard, infrastrutture aperte, contenuti senza restrizioni e strumenti di progettazione open-source per massimizzare la capacità degli individui di fare e utilizzare l'hardware. L'Open Design dà alle persone la possibilità di controllare la loro tecnologia e, allo stesso tempo, di condividere le conoscenze e di incoraggiare il commercio attraverso lo scambio libero di idee. L'Open Design deve essere sempre considerato nella sua dimensione politica perché la trasparenza, la collaborazione e la distribuzione delle risorse sono strategie che da sole non garantiscono pienamente l'equilibrio e la giustizia sociale. Inoltre realizzando progetti open design riveleremo la loro dimensione politica rendendo tutti consapevoli dell'impatto sulla dimensione sociale, economica e ambientale della vita di tutti.

Questa de nizione

di progetto si applica alla progettazione nella sua accezione più ampia e non è limitata a qualche settore speci co. Qui il progetto è inteso come: verbo: progettare qualcosa (in questo senso è considerato come un processo) documentazione: i disegni di un progetto (quindi considerato come un prototipo) risultato: il progetto nella sua versione nale da utilizzare (quindi considerato come un oggetto) Ad esempio l'Open Design potrebbe riferirsi a un progetto di Product Design, Fashion Design, Graphic Design, Interior Design, Service Design, Interaction Design e così via. Per una de nizione speci ca di Open Design relativa a una particolare branca della progettazione, la de nizione corrente può essere sdoppiata ed estesa dall'archivio di de nizioni di Open Design. Un progetto di Design che include software o hardware può essere de nito Open Design se il software è rilasciato sotto una licenza open source approvata OSI, e l'hardware è rilasciato sotto una licenza open source approvata Open Source Hardware. Trat-

da: https://github.com/OpenDesign-WorkingGroup/Open-Design-Definition/ blob/master/open.design_definition/open.design.definition.md [traduzione itato

liana a cura dell'autore].

2.1.

DAL BIT ALL'ATOMO

Figura 2.3: La rappresentazione schematica delle caratteristiche di apertura di discipline diverse applicate a contesti di erenti (Avital, 2011).

diverse da altri tipi di applicazioni open e che deve necessariamente scontrarsi con necessitĂ e modalitĂ di uso diverse (Figura 2.3).

2.1.5 Casi esemplari di Open Design e Open Hardware Conviene forse a questo punto prendere in esame alcune iniziative riconducibili all'open design e tentare di evidenziarne il funzionamento e le tematiche che tali iniziative pongono in essere. L'analisi che viene fatta in seguito non Ă¨ un'analisi comparativa, ma un semplice elenco di esperienze che puĂ˛ risultare utile per comprendere il signi cato di open design nelle sue applicazioni pratiche. I casi sono presentati in ordine casuale e per la maggior parte di loro la descrizione che ne viene fatta Ă¨ direttamente estrapolate dalle informazioni presenti sui rispettivi website. L'obiettivo Ă¨ quello di dare una veduta d'insieme su un fenomeno emergente sottolineando l'esistenza di una sostanziale eterogeneitĂ di temi e approcci ma, al contempo, l'omogeneitĂ in termini di strumenti e strategie.

OpenIdeo

CAPITOLO 2.

OPEN DESIGN

: OpenIDEO Ă¨ un esempio di piattaforma online creata come

spin-o dell'organizzazione madre IDEO (una delle maggiori agenzie di design e consultant innovation della Silicon Valley).

Ă&#x2C6; stata lanciata nel luglio

2010 ed Ă¨ una piattaforma web-based per l'innovazione in cui i progettisti e altri creativi sviluppano iniziative insieme.

L'intento Ă¨ quello di creare

un luogo dove le buone idee guadagnano slancio attraverso la partecipazione attiva e un processo di progettazione strutturata. L'obiettivo di OpenIDEO Ă¨ quello di sfruttare la capacitĂ di IDEO per attrarre talenti in tutto il mondo, incoraggiare la collaborazione attraverso un approccio visivo in modo da superare diverse s de per il bene comune.

Si con gura dunque come una

piattaforma di lavoro e incontro tra utenti che sviluppano di volta in volta i progetti proposti dalla piattaforma stessa.

Openmoko

: Openmoko Ă¨ un progetto di telefono cellulare di tipo smart-

phone completamente Open Source: inizialmente per quanto riguarda il suo software, e in seguito anche per quanto riguarda il suo hardware e il progetto di design. Possiamo a ermare che questo sia stato il primo, vero, prodotto di design di massa, poichĂŠ gli esempi precedenti o non hanno perseguito sino in fondo la loso a Open Source, oppure hanno avuto risultati limitati o il contesto non era pronto per iniziative di questo tipo (Menichinelli 2008). Al momento il progetto Ă¨ concluso e il sito non Ă¨ piĂš aggiornato.

Open Desk

OpenDesk Ă¨ una comunitĂ di designer che si focalizza

sulla produzione di elementi di arredo, principalmente mobili e sedie. Si Ă¨ sviluppata a partire dalla necessitĂ dei promotori di realizzare gli arredi per Hub Westminster, uno spazio di co-working nel centro di Londra. Da allora i modelli digitali sono stati resi disponibili online e con essi i piani di taglio che possono essere letti da una macchina a controllo numerico che produrrĂ i vari componenti.

Attraverso la registrazione al sito e l'accettazione delle

licenze di uso (licenze di tipo Creative Commons per usi non commerciali) Ă¨ possibile ottenere una copia del modello digitale di interesse. L'assemblaggio e le niture vengono poi realizzate dall'utente nale, come anche eventuali modi che (Figura 2.4).

SkecthChair

: SketchChair Ă¨ uno strumento basato su software open-

source che permette a chiunque di progettare e costruire facilmente i pro-

19 http://www.openideo.com/how-it-works/full.html 20 http://wiki.openmoko.org/wiki/Main_Page 21 https://www.opendesk.cc/how-it-works 22 http://www.sketchchair.cc/

2.1.

DAL BIT ALL'ATOMO

Figura 2.4: La homepage del sito di Open Desk: Ă¨ possibile vedere alcuni dei mobili i cui modelli e disegni esecutivi vengono messi a disposizione degli utenti (fonte:

//www.opendesk.cc/).

https:

Figura 2.5: L'homepage di SketchChair, con uno schema esplicativo del processo proposto (fonte

http://www.sketchchair.cc/).

pri mobili attraverso la fabbricazione digitale.

Il programma consente agli

utenti, attraverso alcune tecniche parametriche di gestione del modello tridimensionale, di utilizzare una semplice interfaccia di disegno 2d, generando automaticamente la struttura di una sedia e testarne la sua stabilitĂ . Il software genera automaticamente i pro li di taglio per le sedie, che possono poi essere utilizzati per realizzare sicamente SketchChair. Utilizzando un pantografo di CNC, una macchina a taglio laser o una taglierina, questi pezzi

CAPITOLO 2.

OPEN DESIGN

possono essere tagliati su qualsiasi materiale idoneo a pannelli piani, e quindi facilmente assemblati a mano (Figura 2.5).

Figura 2.6: L'homepage della piattaforma Thingiverse. Si notano alcuni degli oggetti di cui Ă¨ possibile scaricare il modello digitale (fonte:

Thingiverse

http://www.thingiverse.com/).

Thingiverse Ă¨ una piattaforma per condividere modelli

digitali. Si focalizza principalmente sulla stampa in 3d, favorendo la condivisione e la distribuzione di modelli di oggetti che possono essere realizzati con una stampante 3d casalinga. I modelli vengono distribuiti liberamente e possono essere presi, modi cati, redistribuiti da ciascun utente secondo le proprie necessitĂ . Per accedere a tali servizi Ă¨ necessario registrarsi al sito di Thingiverse tramite e-mail (Figura 2.6).

Arduino

: Arduino Ă¨ una piattaforma di prototipazione elettronica open-

source, basata su hardware e software essibile, facile da usare.

Si tratta

di una scheda elettronica piuttosto semplice che permette di creare oggetti o ambienti interattivi ai suoi utenti, siano essi designer, artisti, studenti o semplici appassionati.

Le funzioni di Arduino sono meglio descritte nelle

parole dei suoi fondatori, Arduino can sense the environment by receiving input from a variety of sensors and can a ect its surroundings by controlling

23 http://www.thingiverse.com/about 24 http://arduino.cc/

2.1.

DAL BIT ALL'ATOMO

lights, motors, and other actuators.

The microcontroller on the board is

programmed using the Arduino programming language (based on Wiring) and the Arduino development environment (based on Processing). Arduino projects can stand-alone or they can communicate with software running on a computer (e.g. Flash, Processing, MaxMSP).

Ikea Hacking

: IkeaHackers.net Ă¨ un sito di modi che e riutilizzo dei

prodotti Ikea. L'Hacking puĂ˛ essere semplice come l'aggiunta di un abbellimento, oppure piĂš complicato e richiedere strumenti di lavoro professionali e una certa dose di ingegno. Si tratta dunque di una piattaforma che distribuisce idee e progetti che si propongono di realizzare modi che sui mobili Ikea per adattarli ai propri scopi.

2.1.6 Arduino Questo quadro d'insieme necessariamente non esaustivo e parziale di esperienze di Open Design Ă¨ volto perlopiĂš a fornire una visone generale di ciĂ˛ che succede nel mondo dell'Open Design. In questo paragrafo ci si so ermerĂ su una delle esperienze viste in precedenza provando a comprenderne il processo e le ragioni del suo funzionamento. In questo senso Ă¨ molto interessante l'esperienza di Arduino, l'hardware open source per eccellenza. Oggetto primo di Arduino Ă¨ infatti una schedina elettronica utile per la creazione di piccoli prototipi con componenti elettroniche. Ă&#x2C6; forse uno dei primi esperimenti riusciti (con un certo successo) che applica le regole di sviluppo Open Source non al software o ai contenuti digitali ma a un oggetto reale. Open-source hardware shares much of the principles and approach of free and open-source software.

In particular, we believe that people

should be able to study our hardware to understand how it works, make changes to it, and share those changes. To facilitate this, we release all of the original design les (Eagle CAD) for the Arduino hardware. These les are licensed under a Creative Commons Attribution ShareAlike license, which allows for both personal and commercial derivative works, as long as they credit Arduino and release their designs under

25 Arduino puĂ˛ `comprendere' l'ambiente ricevendo input da una varietĂ di sensori, e puĂ˛ agire sull'ambiente circostante grazie a luci di controllo, motori e altri meccanismi. Il microcontrollore sulla scheda Ă¨ programmato utilizzando il linguaggio di programmazione Arduino (basato su Wiring) e l'ambiente di sviluppo Arduino (basato su Processing). I progetti Arduino possono funzionare in modalitĂ stand-alone o possono comunicare con dei software installati su altri computer (ad esempio Flash, Processing, MaxMSP). [traduzione italiana a cura dell'autore].

26 http://www.ikeahackers.net/about

CAPITOLO 2.

OPEN DESIGN

Figura 2.7: L'home page del sito di Arduino. È possibile vedere un esemplare di scheda prodotta dalla comunità. Fonte:

http://arduino.cc/

the same license. The Arduino software is also open-source. The source code for the Java environment is released under the GPL and the C/C++ microcontroller libraries are under the LGPL.

Nello speci co Arduino è una scheda elettronica dotata di un microcontrollore e circuteria di contorno attraverso la quale, dopo averla opportunamente collegata a sensori o appositi devices (luci, ampli catori, emettitori di vario genere, piccoli motori elettrici etc), è in grado di realizzare piccoli prototipi o installazioni di vario tipo, a scopo didattico, hobbistico o anche professionale. Arduino non è solo la scheda, ma anche il linguaggio di programmazione (sempre open source) e tutti i disegni e le speci che tecniche che ne permettono la costruzione (rilasciati con licenza open source). Ciò signi ca che

27 L'hardware Open-source condivide molti principi e approcci propri del free e opensource software.

In particolare, riteniamo che le persone dovrebbero essere in grado di

studiare il nostro hardware per capire come funziona, per apportare dei cambiamenti e condividerli. Per facilitare ciò, rilasciamo tutti i le del progetto originale (Eagle CAD) per l'hardware Arduino. Questi le sono rilasciati sotto licenza Creative Commons (Attribuzione - Condividi alla stesso modo), la quale permette usi sia privati che commerciali, purché accreditino Arduino e rilascino i loro progetti con la stessa licenza. Anche il software Arduino è open-source. Il codice sorgente per l'ambiente Java è rilasciato sotto GPL e le librerie del microcontrollore C/C++ sono sotto LGPL. [traduzione italiana a cura dell'autore] tratto da:

http://www.arduino.cc/

2.1.

DAL BIT ALL'ATOMO

puĂ˛ anche essere autoprodotta da un utente in grado di farlo. Attualmente Arduino Ă¨ sviluppata, prodotta e distribuita dai suoi sviluppatori iniziali, ma nel contempo la comunitĂ che si Ă¨ creata ha prodotto interessanti fenomeni. Primo tra tutti la comparsa di una serie di produttori e sviluppatori i quali hanno prodotto e commercializzato prodotti a ni, compatibili o direttamente identici, sfruttando le possibilitĂ che la distribuzione libera dei codici e degli schemi elettronici o rono. DopodichĂŠ Ă¨ da segnalare la ricca documentazione circa le applicazioni promesse da Arduino, facendo sĂŹ che acquistare o realizzare una scheda Arduino non signi chi unicamente ottenere una scheda pronta all'uso, ma anche poterla usare immediatamente per una miriade di applicazioni giĂ sviluppate da altri utenti. In ultimo, ma non meno importante, l'architettura aperta della scheda permette di sviluppare le applicazioni piĂš diverse.

Nasce come una scheda per realizzare piccole

installazioni interattive, ma al momento, ad esempio, viene usata per realizzare droni o stampanti 3d. Lo sviluppo Open Source in tutti i suoi aspetti (la versatilitĂ di uso, l'ampia documentazione esistente, l'apertura intrinseca della scheda stessa) l'hanno fatta diventare da giocattolino elettronico a componente per artefatti ad altissimo livello tecnologico (Figura 2.7). Con Arduino si Ă¨ dunque passati da un sistema basato prettamente sull'informazione e sullo scambio di bit (le righe di codice del free software o i testi delle pagine di Wikipedia) a un sistema in cui le informazioni che vengono scambiate apertamente hanno dei ri essi anche sulla realtĂ sica.

2.1.7 Il processo dell'Open Design Sebbene il corpus degli esempi che sono stati presentati possa sembrare piuttosto eterogeneo, sopratutto per quanto riguarda le tematiche che vengono a rontate, Ă¨ perĂ˛ possibile discernere alcuni tratti comuni che caratterizzano tutte queste esperienze. GiĂ individuate in parte nel lavoro di Menichinelli (2008), le caratteristiche fondamentali di questi fenomeni sono tre: la de nizione di una sorgente, la gestione di una comunitĂ e la costruzione di una piattaforma. Vediamo ora nello speci co che cosa signi cano questi tre termini.

La sorgente

La de nizione della sorgente Ă¨ particolarmente libera e si basa

su piĂš fattori, anche molto diversi: in alcuni casi dipende direttamente dalle modalitĂ di produzione che ogni utente Ă¨ idealmente in grado di realizzare (se si tratta di hackerare dei mobili Ikea la sorgente diventano le istruzioni per poterli modi care, se invece ci riferiamo a Sketch Chair la sorgente sarĂ un'interfaccia che ci permette di ottenere degli schemi di taglio pensati per pannelli di materiale rigido disegnando unicamente il pro lo della nostra

CAPITOLO 2.

OPEN DESIGN

sedia...). Il sistema di produzione ha quindi un grande e etto sulle de nizione della sorgente.

Possiamo dire che la sorgente, la sua de nizione e la sua

natura stabiliscono le modalitĂ attraverso cui l'informazione, dalla sua forma digitale, passerĂ ad avere una forma reale e tangibile.

La comunitĂ

L'insieme delle persone che contribuiranno a sviluppare la

sorgente e a implementarla Ă¨ costituito dalla comunitĂ . La comunitĂ Ă¨ l'insieme di utenti che per motivi prettamente personali (che spaziano dal puro interesse alle necessitĂ formative o ad altre necessitĂ ) partecipa all'iniziativa di open design e contribuisce a svilupparne le tematiche e le diverse parti. Molto spesso gli utenti appartengono a delle categorie ben precise: Ă¨ molto facile pensare, e spesso Ă¨ cosĂŹ, che per la maggior parte degli esempi visti la comunitĂ sia composta per lo piĂš da designer o appassionati di elettronica; ma nella realtĂ , ed Ă¨ questa la vera forza del processo di apertura, una iniziativa di open design favorisce, per sua stessa natura, l'avvicinarsi di persone con diversi background. La comunitĂ Ă¨ dunque la curatrice della sorgente, del suo sviluppo e della sua promozione, e si delinea come una sorta di intelligenza collettiva che governa il progetto piĂš che come la sommatoria di tante intelligenze individuali.

La piattaforma

Il punto di incontro tra comunitĂ e sorgente avviene al-

l'interno di una piattaforma opportunamente predisposta. Molto spesso la piattaforma puĂ˛ essere ricondotta al sito web attraverso cui la sorgente viene distribuita e la comunitĂ si ritrova. Nella realtĂ Ă¨ molto piĂš complesso di cosĂŹ. La piattaforma puĂ˛ avere le sembianze di un semplice multi-blog o di un forum ed essere accompagnata da un repository di le; altre volte comprende software e librerie di funzioni anche piuttosto complesse che permettono di lavorare con la sorgente. Invece in altri casi la piattaforma permette di collegarsi direttamente alla produzione, integrando al suo interno ideatori, sviluppatori e produttori allo stesso tempo (Ă¨ quello che succede per Open Desk). La piattaforma Ă¨ l'insieme di regole e strumenti che permettono alla comunitĂ di distribuire, implementare e sviluppare la sorgente.

La de nizione delle tre caratteristiche non Ă¨ a atto casuale, dal momento che le tre componenti rispecchiano, seppur con alcune varianti, le tre funzioni principali coinvolte nel processo comunicativo secondo Benkler (2007, p. 86): c'Ă¨ un enunciato iniziale, portatore di signi cato. [...] Poi c'Ă¨ la collocazione dell'espressione culturale all'interno di una mappa conoscitiva. [..] L'utilitĂ di una porzione di informazione dipende da una valutazione combinata della sua credibilitĂ e della sua rilevanza. [...] In ne c'Ă¨ la fase della distribuzione,

2.1.

DAL BIT ALL'ATOMO

cioĂ¨ il modo in cui si prende un enunciato e lo si di onde ad altre persone che lo trovano credibile e rilevante.

Rileggendo queste righe viene quasi

immediato considerare la sorgente come un enunciato, enunciato che vive e si sviluppa attraverso la sua rilevanza, ovvero attraverso l'interesse che suscita all'interno della comunitĂ . In ne c'Ă¨ la distribuzione e la piattaforma (che distribuisce la sorgente e ospita la comunitĂ ) diventa infrastruttura e veicolo dell'enunciato iniziale. Questa visione non deve perĂ˛ trarre in inganno. Innanzitutto non bisogna considerare il processo come diacronico ma piuttosto come sincronico, contestuale, o comunque non necessariamente dotatto di un ordine temporale.

Il dibattito interno di una comunitĂ puĂ˛ far scaturire la nascita di

una nuova sorgente, una piattaforma ben studiata puĂ˛ favorire il formarsi di nuove iniziative e, piĂš in generale, le convergenze che si formano in rete non sono facilmente prevedibili. Inoltre sebbene la de nizione della sorgente sia e ettivamente un momento di rilevanza assoluta in tutto il processo (si puĂ˛ decisamente parlare di progetto della sorgente, ma lo stesso si potrebbe fare per la piattaforma...), nella realtĂ le dinamiche sono ben piĂš complesse. Si potrebbe infatti pensare che de nendo una sorgente di tipo esclusivo questa possa essere trovata rilevante unicamente dagli addetti ai lavori (a cui e ettivamente Ă¨ indirizzata) e da pochi altri.

In realtĂ questa premessa molto

spesso Ă¨ disattesa e Arduino ne Ă¨ un esempio. Da strumento di interaction design (che e ettivamente potrebbe essere considerato rilevante da un piccola nicchia di persone, gli interaction designer) Ă¨ arrivato a essere distribuito nei grandi magazzini degli Stati Uniti. Questo perchĂŠ la sua natura aperta ne ha immediatamente favorito altri usi e, soprattutto, lo ha fatto diventare rilevante per altri utenti oltre che per i soli interaction designer. Sorgente, comunitĂ e piattaforma sembrano sĂŹ fare il verso alle tre virtĂš teologali (fede, speranza e caritĂ ) ma sono in realtĂ la traduzione che Internet e il Web hanno fatto di un processo comunicativo e produttivo piuttosto complesso, dividendo ciĂ˛ che nei mass media tradizionali era un tutt'uno. Non a caso mezzi di comunicazione di massa come radio, televisione e giornali integrano le tre funzioni in sĂ¨ stesse, non lasciando sostanziale libertĂ di azione all'utente (Ă¨ vero che si puĂ˛ sempre cambiare canale, testata giornalistica, stazione radio, ma oltre al fatto che il numero di opzioni Ă¨ tendenzialmente nito, appare oggi piuttosto chiaro che il livello di interazione con gli utenti sia piuttosto misero).

Viceversa Internet sta rendendo possibile una enor-

me disaggregazione e delocalizzazione delle funzioni comunicative.

E tale

disaggregazione permette ricombinazioni dagli esiti insperati e sorprendenti. Esattamente come avviene nella commutazione di pacchetto, dove l'informazione da trasmettere viene disaggregata in sequenze nite e distinte di dati che vengono poi ricombinate presso il ricevente, anche nel caso delle funzioni

CAPITOLO 2.

comunicative di Internet avviene lo stesso.

OPEN DESIGN

La `pacchettizzazione', cioĂ¨ la

riduzione a entitĂ nite, ha avuto successo, marcando un notevole cambio di passo nello scambio di informazione.

2.1.8 Open-X L'excursus sull'Open Design fa ri ettere su diversi elementi.

Innanzitutto

Ă¨ forse il primo fenomeno in grado di trasformare il frutto della produzione sociale in oggetti sici bypassando la produzione tradizionale, ovvero riesce a creare un processo che da bit ad atomo comprenda unicamente strumenti e utenti che si pongono come alternativa al sistema produttivo legato all'idea della mass production.

Storicamente questo Ă¨ piuttosto rilevante:

non a

caso c'Ă¨ stata la de nizione di `next Industrial revolution' da parte di Chris Anderson.

Nel suo articolo uscito su Wired nel 2010, Anderson descrive

cosĂŹ il fenomeno della digital fabrication distribuita e dell'open design: Peer production, open source, crowdsourcing, user-generated content all these digital trends have begun to play out in the world of atoms, too. The Web was just the proof of concept. Now the revolution hits the real world.

(Anderson

2010a). L'open design diviene dunque la pietra miliare dello sbocco della produzione sociale tra pari, stabilendo un nuovo paradigma e permettendo alla rete di proiettarsi e cacemente nella realtĂ e viceversa. CiĂ˛ puĂ˛ essere considerato come l'inizio di un fenomeno che tenderĂ a espandersi nel futuro, una sorte di megatrend. Come scrive Michel Avital in Open Design Now, nel 2011, circa un anno piĂš tardi dell'articolo di Anderson: From a social perspective, openness is a core characteristic of an infrastructure that conveys and reinforces sharing, reciprocity, collaboration, tolerance, equity, justice and freedom. The application of openness, as implied by various accessibility features, to a growing number of central ubiquitous practices that drive the human enterprise, has turned into a megatrend that can be labelled the Rise of Open-X. Megatrends are widespread trends which have a major impact and are likely to a ect all levels individuals, organizations, markets, countries and civil society for a long duration. Understanding megatrends and their rolling e ects can provide valuable information for developing futuristic scenarios and can subsequently help to shape current actions in anticipation of that future.

(Avital 2011).

28 Produzione tra pari, open source, crowdsorcing, contenuti generati dagli utenti tutte queste tendenze digitali hanno iniziato a giocare anche nel mondo degli atomi. Il Web Ă¨ stato solo la prova del concetto. Ora la rivoluzione ha colpito il mondo reale. [traduzione italiana a cura dell'autore].

29 Da una prospettiva sociale, l'apertura Ă¨ la caratteristica principale di una infrastrut-

2.1.

DAL BIT ALL'ATOMO

Se la produzione sociale acquista la possibilitĂ di svilupparsi e agire non solo all'interno della rete ma anche al di fuori, potendo e ettivamente modi care la realtĂ e plasmare la forma sica, Ă¨ possibile pensare che ciĂ˛ possa avvenire non solo nel mondo del design (la cui scala e ettivamente favorisce il veri carsi del fenomeno) ma anche in altri campi, tra cui l'architettura. L'esperienza dell'Open Design rimane comunque importantissima anche per il fatto di avere giĂ costruito alcuni scenari e strumenti utili che, come vedremo in seguito, verranno presi in considerazione anche da altri tipi di approcci e discipline.

tura che convoglia e rinforza la condivisione, la reciprocitĂ , la collaborazione, la tolleranza, l'equitĂ , la giustizia e la libertĂ . L'applicazione dell'apertura, come implicito da varie caratteristiche di accessibilitĂ , a un crescente numero di pratiche centrali onnipresenti che guidano l'impresa umana, si Ă¨ trasformata in un megatrend che puĂ˛ essere etichettata come Nascita dell'Open-X. I megatrends sono tendenze di use che hanno un impatto importante e sono in grado di in uenzare tutti i livelli - individui, organizzazioni, mercati, paesi e societĂ civile - per una lunga durata. Capire i megatrend e i loro e etti puĂ˛ essere utile per avere preziose informazioni per sviluppare scenari futuristici e, di conseguenza, puĂ˛ aiutare a modellare le azioni attuali in previsione di quel futuro. [traduzione italiana a cura dell'autore].

Parte II Architettura Open Source

The rst step towards an open-source practice in architecture is to develop a broad-based awareness that cooperation and the opening up of architectural practice to input from outside are important requirements if an e ective contribution is to be made to the ever-more complex spatial processes.

(Kaspori 2003)

Nei capitoli precedenti si Ă¨ visto come il mondo Open stia pian piano conquistando molti campi del sapere e dell'agire umano, e in particolare si Ă¨ potuto osservare come il fenomeno dell'Open Source abbia avuto signi cative conseguenze nel mondo del design, modi candone processi ed esiti. Ă&#x2C6; quindi lecito pensare che tale tipo di approccio, l'approccio Open Source, possa anche essere introdotto nel campo dell'architettura. Si vedrĂ come negli ultimi anni questa idea si sia a acciata sulla scena del dibattito architettonico, grazie principalmente all'attivitĂ delle riviste e delle comunitĂ online. Prima di avvicinarci ai temi e ai fenomeni della contemporaneitĂ , Ă¨ perĂ˛ utile rileggere e rivedere alcune interessanti esperienze del passato, le quali permettono, alla luce dell'odierna rivoluzione digitale, di comprendere meglio come e perchĂŠ l'idea di una analogia e cace tra Open Source e architettura abbia solide basi teoriche e si fondi su una comprovata tradizione di pensiero architettonico. Si vedrĂ come l'analogia tra Open Source e processo architettonico possa essere considerata diretta discendente di alcune teorie che dagli inizi degli anni Sessanta hanno cominciato a mettere in seria discussione il movimento moderno e l'idea di architetto demiurgo. La partecipazione, e piĂš nello speci co la partecipazione mediata dalla tecnologia, divengono temi di esplorazione (al pari di tanti altri) di alcuni architetti del periodo. Alcuni di questi si scontrarono in maniera aperta con i modi con cui il sistema produttivo a rontava la crescente domanda di abitazioni, criticando n da subito la svolta verso la prefabbricazione pesante e la conseguente standardizzazione in termini di o erta e qualitĂ abitativa, mettendo a punto sistemi e metodi in cui gli utenti erano parte integrante del processo edilizio e ricoprivano ruoli che no ad allora gli erano preclusi. Si prenderanno in considerazione alcune delle esperienze che posonno essere considerate esperienze di partecipazione mediata dalla tecnologia, dove per tecnologia si intende un insieme di strumenti e arti ci attraverso i quali

30 Il primo passo verso un'applicazione open source in architettura Ă¨ quello di sviluppare la consapevolezza che la cooperazione e l'apertura della pratica architettonica verso l'esterno sono requisiti importanti, che possono dare contributi sostanziali in processi sempre piĂš complessi di trasformazione dello spazio costruito. [traduzione itliana a cura dell'autore].

avviene il coinvolgimento dell'utente all'interno del processo edilizio.

Ven-

gono presi in considerazione autori come Christopher Alexander, N. John Habraken, Yona Friedman e Walter Segal. Tali autori hanno sviluppato, in modi e periodi di erenti, le loro visioni e i loro metodi di coinvolgimento dell'utente in totale opposizione ai principi edilizi allora imperanti. Nel quarto capitolo vengono presi in esame sei casi studio. Si tratta di iniziative recenti, il cui principale obiettivo Ă¨ quello di applicare il metodo di sviluppo Open Source all'interno del processo architettonico.

I sei casi

studio vengono analizzati sulla base delle tre componenti che caratterizzano ogni progetto Open Source: la sorgente, la comunitĂ e la piattaforma. Oltre a queste tre chiavi di lettura vengono presi in esami altri elementi, come ad esempio chi siano i promotori e quali modelli di business e di nanziamento vengono messo in atto.

Dai dati emersi sarĂ possibile stabilire che cosa Ă¨

l'Architettura Open Source e de nire in seguito alcuni strumenti operativi che la pongono in essere.

Capitolo 3 Architettura aperta 3.1

Processo e utente

3.1.1 Opera aperta A partire dai primi anni Sessanta si comincia a ri ettere circa la produzione delle opere d'arte e della loro fruizione, ri essione che sfocia in un dibattito innescato da una raccolta di saggi del 1962 di Umberto Eco, dal titolo

Opera Aperta. Il libro nasce da un intervento dello stesso Eco al XII Congresso Internazionale di Filoso a tenutosi a Venezia nel 1958, dal titolo Il

problema dell'opera aperta.

All'interno del primo articolo viene evidenzia-

ta, da parte dell'autore, l'apparizione, in questi ultimi tempi, ed in settori di erenti, di opere la cui `inde nitezza', la cui apertura, il fruitore puĂ˛ realizzare sotto l'aspetto produttivo. (Eco 1958). Eco si riferisce in questo caso, con il termine `indi nitezza', a opere che si presentano non complete o ultimate, per la quali la fruizione consiste nel completamento dell'opera, e in tale completamento si esaurisce anche l'atto interpretativo, poichĂŠ attraverso l'interpretazione si manifesta anche la visione particolare che il fruitore ha dell'opera. Ad esempio di quanto appena illustrato, Eco porta l'edi cio della FacoltĂ di Architettura di Caracas, in Venezuela, dell'architetto Carlos Raul Villanueva (tale edi cio era stato presentato in un articolo di Bruno Zevi sull'Espresso di quell'anno): Un primo esempio da citare ci pare la recente costruzione della FacoltĂ di Architettura dell'UniversitĂ di Caracas; questa scuola di architettura Ă¨ stata de nita una scuola da inventare ogni giorno e costituisce un notevole esempio di architettura in movimento. Le aule di questa scuola sono costruite mediante pannelli mobili in modo che professori e allievi, a seconda del problema architettonico e urbanistico in discussione, si costruiscano un ambiente di studio acconcio, modi cando la disposizione e la sionomia estetica del locale (Figura 3.1). Anche qui il modo di ideazione

CAPITOLO 3.

ARCHITETTURA APERTA

Figura 3.1: Vista di uno degli atelier della facolatĂ di architettura di Caracas. La pianta libera e la possiblitĂ di spostare i pannelli di tamponamento permettono svariate combinazioni della pianta (fonte:

http://www.fau.ucv.ve).

della scuola ha determinato il campo delle possibilitĂ formative, rendendo possibile solo una certa serie di elaborazioni sulla base di una struttura data permanentemente: ma in e etti l'opera non si presenta piĂš come forma de nita una volta per tutte, ma come un campo di formativitĂ . (Eco 1958) Lo scritto di Eco continua con esempi presi in prestito dalla produzione musicale dell'epoca, esempi che poi costituiranno il corpus principale di analisi (insieme con le opere di Joyce) del libro che vedrĂ la luce qualche anno dopo. Potrebbe sembrare alquanto singolare che proprio un'opera architettonica (insieme ad alcune composizioni musicali di Pousseur, Berio, Stockhausen e Boulez) venga presa ad esempio da Eco per a rontare il problema dell'opera aperta.

In realtĂ , come scriverĂ Nelson Goodman qualche anno piĂš tardi

(nel 1968) nel suo libro I linguaggi dell'arte, le piante architettoniche, come gli spartiti musicali, possono talora de nire le opere in termini piĂš ampi di quanto comunemente le intendiamo . Goodman sostiene che musica e architettura condividono una sostanziale natura allogra ca. Eco si riferisce perciĂ˛ a musica e architettura in quanto discipline all'interno delle quali Ă¨ prevista una rigorosa sintassi, la dimensione sico-materiale (dell'opera, n.d.r.) viene preservata, dal momento che [...]

l'opera non Ă¨ lo spartito ma la clas-

se delle esecuzioni congruenti con quello spartito (Marchetti 2006).

Per

l'architettura il discorso Ă¨ analogo (seppur con alcune di erenze): non dobbiamo lasciarci ingannare dal fatto che la classe di congruenza di un insieme di piante nisca tanto spesso per consistere in un solo edi cio; o dall'interesse o dal valore superiore che un dato esemplare di un'opera architettonica puĂ˛ possedere; o dall'enfasi con cui talora si sottolinea la supervisione diretta, da parte dell'architetto, sul processo di costruzione.

Molte composizioni sono

suonate una volta sola; certe esecuzioni di altri pezzi hanno un'importanza del tutto particolare; e un edi cio o un'esecuzione realizzati sotto la direzione del progettista o del compositore, anche se sono un prodotto piĂš personale e

3.1.

PROCESSO E UTENTE

magari molto migliore (o peggiore) di un altro edi cio o di un'altra esecuzione, non sono per questo un esemplare piĂš autentico o originale dell'opera. (Goodman 1976). Partire da musica e architettura per organizzare il discorso sull'opera aperta signi ca partire da discipline che, per loro natura, non solo sono indipendenti dal segno gra co dall'autore, ma possono anche prevedere diverse riproduzioni non necessariamente ad opera dell'autore originale. Il fatto che siano indipendenti dall'autore e riproducibili da altri permettono al fruitore di avere un ruolo automaticamente diverso dal ruolo che avrebbe contemplando un quadro, ovvero un ruolo in qualche modo attivo, che puĂ˛ anche essere sviluppato e ampliato e, in alcuni casi, de nito a priori. Si stabilisce dunque una nuova forma di ideazione e fruizione dell'opera d'arte, una forma che eleva il fruitore a collaboratore dell'autore, secondo forme e modalitĂ di erenti: Indubbiamente dal barocco alle odierne poetiche del simbolo si Ă¨ andato sempre piĂš precisando un concetto di opera dall'esito non univoco [...].

Invece una composizione come Scambi di Pousseur

rappresenta qualcosa di ulteriore:

mentre ascoltando un'opera di Webern

l'ascoltatore liberamente riorganizza e fruisce una serie di relazioni nell'ambito dell'universo sonoro o ertogli (e giĂ completamente prodotto), in Scam-

bi il fruitore organizza la struttura, dal lato stesso della produzione della manualitĂ , il discorso musicale. Collabora a fare l'opera. (Eco 1962) .

3.1.2 La ne dell'architetto demiurgo Il tema dell'opera aperta, del fruitore che collabora a fare l'opera, viene approfondito, per quanto concerne l'architettura, da un giovane architetto francese, Philippe Boudon, il quale compie un'indagine all'interno del quartiere Pessac di Le Corbusier, nei pressi di Bordeaux. Pessac, uno dei primi quartieri interamente costruiti da Le Corbusier, ha costituito un interessante esperimento di industrializzazione della costruzione e produzione in serie. Infatti per la prima volta si erano usate macchine e attrezzature normal-

mente non utilizzate nell'edilizia civile , le quali modi carono radicalmente il processo costruttivo, avvicinandolo molto di piĂš a un sistema di produzione fordista piuttosto che a un normale cantiere edile dell'epoca. Questo tipo di atteggiamento, unito al progetto di Le Corbusier, ebbe delle ripercussioni sia sulla velocitĂ della costruzione (notevolmente diminuita) che sul risultato nale, piuttosto distante dalle tradizionali abitazioni che si era soliti incontrare nel bordolese, le cosiddette `ĂŠchoppes'.

Nel 1969, a quarant'anni di

1 I macchinari utilizzati da Le Corbusier nel cantiere della CitĂŠ FrugĂŠs arrivavano infatti dall'edilizia militare, che aveva fatto enormi sforzi costruttivi durante la prima guerra mondiale per forti care il fronte occidentale.

CAPITOLO 3.

ARCHITETTURA APERTA

Figura 3.2: Abaco delle modi che realizzate dagli abitanti di Pessac tratto da Boudon (1983). In alto a sinistra la pianta originale di Le Corbusier.

distanza dall'inaugurazione del complesso (avvenuta in pompa magna, con tanto di ministro e discorsi u ciali) Boudon va a Pessac e trova un quartiere che, ad eccezione dell'impianto urbano, non assomiglia per nulla a quello che era stato consegnato ai suoi primi residenti. Le modi che alle abitazioni eseguite dagli abitanti stessi ne avevano completamente modi cato l'aspetto: al posto dei tetti piani si trovavano tetti a doppia falda; dove c'era una nestra a nastro ora vi erano due o più nestre a doppia anta; le porzioni di piano libero a pilotis erano state chiuse e gli inquilini vi avevano ricavato un nuovo ambiente.

La de nizione forse più e cace di ciò che era successo è conte-

nuta nel titolo del libro che riunisce le analisi di Boudon nella sua versione inglese: Lived-in architecture, architettura vissuta (Figura 3.2). Esattamente come per la facoltà di Caracas, l'opera non si presenta più con una sua forma de nita ma come una forma in divenire, che viene adattata alle necessità dell'utente. Se nel libro di Boudon molti degli intervistati criticano apertamente l'architettura originalmente costruita da Le Corbusier, bisogna però evidenziare che solo una de nizione architettonica di quel tipo avrebbe potuto permettere tali modi che dal momento che, con molta probabilità, una de nizione di tipo tradizionale (sia per le tecniche costruttive che per la sua forma) sarebbe stata molto più di cile da modi care. Quella che da mol-

3.1.

PROCESSO E UTENTE

ti viene letta come una scon tta di Le Corbusier, da altri invece potrebbe venire intesa come una signi cativa conquista, la quale, attraverso la costruzione di massa, favorisce in realtĂ una `customizzazione' di massa, ovvero la possibilitĂ per ciascun utente di apporre le modi che necessarie secondo le sue necessitĂ (lo scheletro della Maison Dom-Ino altro non era che una infrastruttura su cui costruire la propria casa, anche se non era in discussione che fosse l'architetto a disegnarla e costruirla, e non l'abitante). Sta di fatto che l'indagine di Boudon, a cavallo tra l'inchiesta sociologica sul rapporto degli abitanti con l'architettura moderna e l'analisi e il rilievo delle e ettive modi che e superfetazioni che insistono sugli edi ci originali, fa emergere un sostanziale cambiamento dei presupposti che si erano palesati all'interno del movimento dell'architettura moderna. Si iniziava infatti (principalmente attraverso l'attivitĂ del Team X in seguito al CIAM 10 tenutosi a Dubrovnik) a mettere in discussione le pratiche dell'architetto-demiurgo evidenziandone l'approccio paternalistico piuttosto riduttivo, non sempre in grado di spiegare la complessitĂ della vita moderna e di sviluppare sistemi in grado di consentire l'espressione dei bisogni relazionali dell'uomo nella societĂ .

visione che iniziava a prevalere era dunque quella di progettare architetture in grado e di trascendere la tecnica pura del funzionalismo modernista, e di essere ricettive nei confronti delle imprevedibili e sempre mutevoli esigenze personali.

3.1.3 L'utente all'interno del processo edilizio Si delinea un nuovo atteggiamento produttivo in cui il fruitore di un'opera collabora alla sua realizzazione. Tale collaborazione non Ă¨ sempre una collaborazione totale ma deve essere inserita all'interno di un processo speci co che, nel nostro caso, Ă¨ quello edilizio, ed operarvi. Attualmente all'interno del processo produttivo di un'architettura, in generale, il fruitore Ă¨ sostanzialmente poco presente. Secondo i modelli indicati da Turin (2003), nel suo articolo Bulding as a a process, l'utente Ă¨ presente unicamente nella prima fase di processo, quella in cui vengono stabilite le sue esigenze, e nell'ultima fase, ovvero la fase di fruizione dell'opera.

Secondo Turin infatti esistono

all'incirca 4 categorie attraverso le quali Ă¨ possibile descrivere il processo edilizio: `one-o ' approach, `component' approach, `model' approach, and `process' approach (Turin 2003).

Ciascuno di questi approcci al processo

edilizio prevede gradi diversi di coinvolgimento di impresari e produttori di componenti edilizi, ma sempre lo stesso tipo di coinvolgimento dell'utente nale: egli viene consultato unicamente al ne di conoscere le sue personali esigenze riguardo la sua futura abitazione (Figura 3.3).

CAPITOLO 3.

ARCHITETTURA APERTA

Figura 3.3: Schema del modello one-o , tratto da Turin (2003).

Bisogna perĂ˛ osservare che non Ă¨ scontato che l'utente debba venire necessariamente interpellato nella fase di de nizione delle sue esigenze.

Nel

processo di costruzione di massa si Ă¨ fatto spesso riferimento all'utente medio, dui cui Friedman (1972, p. 27) dĂ questa de nizione: il committente (l'utente) medio Ă¨ un personaggio inesistente! Pertanto se si soddisfano solo le esigenze dell'utente medio che non esiste, di conseguenza un utente reale non avrĂ mai soddisfatte esigenze speci che. CosĂŹ invece di soddisfare l'utente reale (che esiste), soddisferemo quello che non esiste. (Figura 3.4).

In questo senso la Pessac descritta da Boudon non Ă¨ altro che il risultato di un processo in cui Ă¨ stato preso in considerazione un utente medio, tuttavia l'uso da parte dell'utente reale ha dimostrato che le esigenze dell'utente medio di cilmente coincidono con le esigenze dell'utente reale. Questo tipo di fenomeno, per cui il manufatto nale si modi ca in seguito alla sua conclusione, o un tipo di fenomeno analogo, per il quale l'utente interviene collaborando all'opera in momenti diversi dall'inizio e dalla ne del processo, puĂ˛ avvenire in maniera spontanea (come nel caso di Pessac) o essere piani cata.

Nella seconda ipotesi Ă¨ necessario perĂ˛, da parte del progettista,

dotarsi di opportuni strumenti che facilitino e favoriscano la presenza dell'utente nelle diverse fasi del processo edilizio.

Tali strumenti possono essere

de niti come strumenti di coinvolgimento.

3.1.4 Strumenti di coinvolgimento This vision of technology mediated participatory design, evolved around the use of computer-aided design and (information) technology as a means to encourage user participation and to empower non-experts to directly express their needs and desires beyond or without the mediation

3.1.

PROCESSO E UTENTE

Figura 3.4: Schema illustrativo rappresentante la nzione dell'utente medio. Diagramma tratto da Friedman (1974).

of the architect. The combination of this pre-computational historical precedent, which has left a heritage of concepts, diagrams and science ctional representations (ie. megastructure, design ampli ers etc) with the growing discourse on open source and the a ordances o ered by information technology, creates the potential for a re-problematization of participatory design under the light of this new paradigm.

2 Tale visione della progettazione partecipata mediata dalla tecnologia si Ă¨ evoluta in ambito della progettazione assistita da computer e della tecnologia dell'informazione proprio come mezzo per incoraggiare la partecipazione dell'utente, e dare la possibilitĂ ai `non esperti' di esprimere direttamente le loro esigenze e i loro desideri aldilĂ o senza la mediazione dell'architetto. La combinazione di questo precedente storico pre-computazionale, il quale ha lasciato un'ereditĂ di concetti, diagrammi e rappresentazioni fantascienti che (come ad esempio megastrutture, ampli catori progettuali, etc.)

con il crescente

discorso sull'open source e grazie all'accessibilitĂ o erta dalla tecnologia, crea le basi per ri-problematizzare la progettazione partecipata alla luce di questo nuovo paradigma. [traduzione italiana a cura dell'autore].

CAPITOLO 3.

ARCHITETTURA APERTA

(Vardouli 2011b) Il processo architettonico non prevede un coinvolgimento ampio dei suoi utenti, al contrario di quanto accade nei modelli open source applicati al software o al design, i quali ampliano ed estendono il ruolo dell'utente all'interno dei loro processi.

Per quanto riguarda l'architettura, era chiaro ad alcuni,

giĂ a partire dal secondo dopoguerra, che la produzione di massa di abitazioni avrebbe portato ai quei fenomeni di alieantion and despair which many people feel, is created, at least in large part, by the depressing burden of this mass housing in which people are forced to spend their lives. (Alexander,

Davis, Martinez & Corner 1985) . Era altresĂŹ chiaro che per ottenere altri risultati si dovesse tenere conto delle reali necessitĂ dell'utente nale piuttosto che quelle di un famigerato utente medio. Questi atteggiamenti potrebbero essere a prima vista inseriti in quello che normalmente viene identi cato con la progettazione partecipata. Dal momento che la partecipazione Ă¨ un tema complesso che non Ă¨ perĂ˛ l'oggetto di questa tesi, verrĂ riportata una e cace de nizione tratta da Bocco & CavagliĂĄ (2008): Diversi autori hanno proposto schemi per classi care la partecipazione. Waters distingue, in ordine decrescente: self help (i cittadini fanno da sĂŠ), partnership (sono partner con medesima dignitĂ rispetto all'istituzione pubblica), consultazione (sono coinvolti nel processo decisionale ma senza potere formale), informazione (ricevono passivamente quanto Ă¨ deciso da altri). Sono ritenuti autentica partecipazione solo i primi due. Lo stesso schema riconosce anche quattro fasi temporali del processo - avvio, piani cazione, realizzazione, gestione - e a erma che perchĂŠ la partecipazione sia autentica deve attribuire agli abitanti un ruolo attivo almeno nelle prime due fasi. Evidentemente, si ha partecipazione al massimo grado quando i cittadini sono contemporaneamente ideatori, costruttori e utilizzatori del proprio spazio abitativo. Si evince che l'importante non Ă¨ solo partecipare, come recita il mantra olimpico, ma anche farlo nella giusta misura (Figura 3.5).

Le pratiche

di coinvolgimento dell'utenza sono diventate pratica comune sopratutto nei paesi del Nord Europa, e alcuni dei partecipanti degli ultimi CIAM ne hanno adottato in parte gli strumenti (si pensi all'attivitĂ di Ralph Erskine, o al villaggio Matteotti di De Carlo). Ai ni di questa tesi non verrĂ perĂ˛ a rontato il dibattito sulla partecipazione nella sua interezza, ma ci si concentrerĂ su quella che Ă¨ stata de nita, come si Ă¨ visto in apertura di questo paragrafo, `technology mediated participatory design', ovvero sul processo partecipato mediato dalla tecnologia. Nel capitolo successivo verranno prese in conside-

3 il sentimento di alienazione e disperazione che molte persone sentono Ă¨ dovuto, in larga parte, dall'aspetto deprimente che hanno le abitazioni prodotte in massa in cui le persone sono costrette a vivere . [traduzione italiana a cura dell'autore].

3.1.

PROCESSO E UTENTE

Figura 3.5: Schema di Habraken rappresentante le varie tipologie di partecipazione. Tratto da Negroponte (1975).

razione alcune delle iniziative e delle ri essioni che possono essere ricondotte

all'idea di partecipazione mediata dalla tecnologia : teorie e progetti che hanno predisposto degli strumenti pensati per garantire l'apertura del processo edilizio.

Le iniziative e gli studi riconducibili alla partecipazione mediata

dalla tecnologia si pongono l'obiettivo (obiettivo progettuale) di sviluppare degli strumenti adeguati atti a garantire un'apertura del processo edilizio nella sua totalità.

Prima ancora di sviluppare il progetto in sé e per sé, è

dunque necessario de nire gli strumenti che garantiscono una partecipazione adeguata all'utente nale, e tali strumenti diventano oggetto di progetto. Nel prossimo capitolo verranno esaminati i contributi di alcuni autori la cui attività è riconducibile a quanto n qui detto. Tale operazione viene fatta

4 La tecnologia va intesa nell'accezione di scienza dei mezzi impiegati per produrre ciò che è necessario a una società e dottrina dei processi di trasformazione assunti sia nel loro costruirsi materialmente (cioè lo studio dei processi tecnici), sia, e soprattutto, nel loro costituirsi cognitivamente (Bocco & Cavagliá 2008).

CAPITOLO 3.

ARCHITETTURA APERTA

nella convinzione che the emergence of the demand for the `democratization' of architecture through the mediation of technology can bene t from an investigation on the way technology was conceptualized in pre-computational

examples. (Vardouli 2011a) .

3.2

Architettura aperta

In questa sezione verranno esaminati i lavori e gli scritti di quattro architetti che hanno operato principalmente nella seconda metĂ del XX secolo. Il loro lavoro viene preso in considerazione in quanto a ronta i problemi che sorgono tra progettista e utenti, e tra opera architettonica e utenti; gli stessi problemi che Boudon ha fatto emergere con e cacia nella sua analisi su Pessac.

vedrĂ come gli esempi citati partano da presupposti sostanzialmente uguali, per approdare a conclusioni anche radicalmente diverse, e come questo insieme di soluzioni possano essere rilette alla luce del paradigma della `network society'. Le posizioni di partenza si possono sintetizzare con un'aperta critica al sistema di `mass-housing', frutto della prefabbricazione pesante e di una domanda di abitazioni decisamente alta in seguito alla ricostruzione successiva al secondo dopoguerra e al boom economico europeo e americano. I risultati dello loro ricerche sono invece piuttosto eterogenei ma hanno numerosi tratti in comune. In primo luogo superano la partecipazione intesa come consultazione o mera informazione degli utenti nali, in quanto si pongono l'obiettivo di sviluppare strumenti in grado di implementare il `self-help' (secondo diversi gradi e modalitĂ ). In secondo luogo si tratta di esperienze all'interno delle quali l'architetto, pur non adottando un atteggiamento di tipo paternalistico, non lascia che il progetto venga sviluppato da altri ma, con i mezzi tipici della sua professione, progetta e sviluppa strumenti adeguati a un nuovo tipo di rapporto tra opera costruita e utenza nale. Ognuno di questi autori si concentra su aspetti di erenti: Alexander si concentra sulla de nizione delle necessitĂ dei fruitori e sulla loro rappresentazione; Habraken divide il progetto tra ciĂ˛ di cui si occupa l'architetto (i `supports') e ciĂ˛ di cui si potrĂ occupare nel futuro l'utente (`in ll'); Friedman potrebbe essere inteso come una sintesi dei due precedenti ma con un'attenzione ai processi di interazione e ai nuovi strumenti computazionali; Segal invece si concentra su elementi propri della cultura tecnologica e su strumenti pratici.

5 la crescente domanda di `democratizzazione' dell'architettura attraverso la mediazione tecnologica puĂ˛ bene ciare di una lettura dei teorici pre-computazionali circa la loro concettualizzazione dell'aspetto tecnologico - inclusivo [traduzione italiana a cura dell'autore].

3.2.

ARCHITETTURA APERTA

3.2.1 Alexander e il `pattern language' The ultimate object of design is form.

The reason that iron lings

placed in a magnetic eld exhibit a pattern - or have form, as we say - is that the eld they are in is not homogeneous.

(Alexander 1964)

Nel 1964 viene dato alle stampe Note sulla sintesi della forma, un libro il cui autore Ă¨ un giovane architetto americano (all'epoca ha 28 anni), Christopher Alexander. Il libro si interroga circa il processo di de nizione di una forma architettonica, partendo dalla considerazione che il processo progettuale necessita di estrema razionalitĂ piuttosto che di arbitrarietĂ : Today functional problems are becoming less simple all the time.

But designers

rarely confess their inability to solve them. Instead, when a designer does not understand a problem clearly enough to nd the order it really calls for, he falls back on some arbitrarily chosen formal order. The problem, because of its complexity, remains unsolved. (Alexander 1964, p. 1)

Nel suo libro Alexander pone l'accento sull'importanza della de nizione chiara del problema architettonico e sulla sua scomposizione e rappresentazione, spiegando che la soluzione formale deriva dall'insieme delle singole soluzioni, le quali possono essere rappresentate da opportuni diagrammi, o pattern. Scrive cosĂŹ Alexander nell'introduzione del libro a dieci anni dalla prima edizione: The idea of a diagram, or pattern, is very simple. It is an abstract pattern of physical relationships which resolves a small system of interacting and con icting forces, and is independent of all other forces, and of all other possible diagrams.

The idea that it is possible to create such

abstract relationships one at a time, and to create designs which are whole by fusing these relationships-this amazingly simple idea is, for me, the most

important discovery of the book. (Alexander 1973).

In tutta la sua pro-

duzione successiva Alexander porrĂ l'accento proprio sulla de nizione, sulla

6 L'obiettivo del progettare Ă¨ la forma. La ragione per cui la polvere metallica posta in campo magnetico esibisce dei `pattern' - o, come comunemente detto, prende forma Ă¨ che il campo all'interno del quale viene posta non Ă¨ omogeneo. [traduzione italiana a cura dell'autore].

7 Al giorno d'oggi i problemi funzionali sono molto meno semplici di un tempo. Ma

i progettisti raramente confessano di non essere in grado di a rontarli.

Al contrario,

quando un progettista non comprende un problema progettuale abbastanza chiaramente da trovarne la giusta soluzione, decide per un qualche arbitrario ordine formale. Il problema, a causa della sua complessitĂ , rimane irrisolto. [traduzione italiana a cura dell'autore].

8 L'idea di un diagramma, o `pattern', Ă¨ piuttosto semplice. Si tratta di una con gura-

zione astratta di relazione siche che risolvono un piccolo sistema di forze che interagiscono e sono al contempo in con itto tra loro, e questa con gurazione Ă¨ indipendente da tutte le altre forze, da tutte le altre possibili con gurazioni. L'idea che sia possibile creare, una alla volta, delle connessioni cosĂŹ astratte, e di creare dei progetti unici che sono il frutto

CAPITOLO 3.

ARCHITETTURA APERTA

descrizione e sull'uso (attraverso anche applicazioni sperimentali) di quello che lui stesso chiamerĂ `pattern language', il linguaggio dei pattern. Si tratta di un insieme di 253 elementi base, i `pattern' per l'appunto, i quali si presentano come dei pacchetti-modello che contengono soluzioni generiche a speci che problematiche (Silvestri 2009). Il tutto compone una grammatica spaziale generativa, il `pattern language', pensata come un insieme di elementi singoli che combinati insieme, senza una particolare esperienza ma con un'attenta de nizione delle problematiche iniziali, sono in grado di risolvere anche complesse questioni progettuali.

I `pattern' possono rispondere

a problematiche di diverso tipo: la loro organizzazione in diverse categorie, ognuna delle quali rivolta a una speci ca tematica, permette loro di spaziare dalle questioni di piani cazione regionale no alla disposizione del salotto, a rontando anche problemi squisitamente tecnici che riguardano ad esempio le tecniche costruttive e l'organizzazione del cantiere. I `pattern' divengono quindi una risorsa per la costruzione di nuovi insediamenti per le comunitĂ locali, la cui ricombinazione Ă¨ in grado di rispondere alle problematiche piĂš variegate: ...each pattern represents our current best guess as to what arrangement of the physical environment will work to solve the problem presented. The empirical questions center on the problem does it occur and is it felt in the way we have described it? and the solution does the arrangement we propose in fact resolve the problem? And the asterisks represent our degree of faith in these hypotheses. But of course, no matter what the asterisks say, the patterns are still hypotheses, all 253 of them and are therefore all tentative, all free to evolve under the impact of new experience and observation. (Alexander, Ishikawa, Silverstein, Jacobson, Fiksdahl-King & Angel 1977, p.

xv).

Esempi di applicazioni del linguaggio dei pattern In order to get a reasonable house which works well and which nevertless expresses the uniquieness of each family, the families all use dell'intreccio di queste connessioni, questa idea semplice e stupefacente Ă¨, per quanto mi riguarda, la piĂš grande scoperta del libro [traduzione italiana a cura dell'autore].

9 Ogni `pattern' rappresenta la nostra migliore risposta, in termini di organizzazione

spaziale dell'ambiente costruito, al ne di risolvere il problema proposto.

Le domande

empiriche tentano di inquadrare il problema (siamo in grado di descrivere il problema per come si manifesta e per come viene percepito?) e la sua soluzione (la risposta che diamo risolve il problema?). E gli asterischi rappresentano il nostro margine di errore in queste ipotesi.

Ma, ovviamente, non Ă¨ importante ciĂ˛ che l'asterisco dice, dal momento che si

tratta comunque di ipotesi, tutte e 253 sono ipotesi, e allo stesso tempo sono tentativi, tutti liberi di evolversi sotto la spinta di nuove esperienze e osservazioni [traduzione italiana a cura dell'autore].

3.2.

ARCHITETTURA APERTA

an instrument we call the pattern language.

(Alexander et al. 1985)

Il `pattern language' è stato applicato da Alexander e dal suo gruppo di ricerca a Berkeley, il Center for Environmental Studies, in diverse occasioni.

La più documentata è sicuramente la realizzazione di un insediamento

a basso costo per una piccola cooperativa di abitanti a Mexicali, in Messico nel 1976. Questa esperienza viene riportata per intero all'interno di un altro dei suoi libri, The production of houses, del 1985, e dettagliatamente illustrata (Figura 3.6). Ne emerge un interessante esperimento di progettazione e costruzione collaborativa all'interno del quale i pattern fungono da strumento di orientamento delle scelte.

Dal disegno alla scala urbana no

alla de nizione dei serramenti e delle aperture, Alexander illustra un metodo alternativo di costruzione di abitazioni (la `production of houses' del titolo), sviluppando un processo completamente alternativo alla produzione di massa seriale dell'epoca: the alienated character of the building which are produced is, in the end, a direct consequence of the deep structure of the production systems; and this character cannot be substantially improved until the system themselves are alterated at the roots .

(Alexander et al. 1985).

Basandosi sulla partecipazione degli utenti nali interessati dal processo e su un coinvolgimento totale che abbraccia tutte le sue fasi, il nuovo metodo di produzione di abitazioni rende libero l'individuo, ma pone dei limiti ad alcune fra le caratteristiche più speculative (e inumane) dell'industria delle costruzioni, riscontrando così i dissensi degli operatori cresciuti nella tradizione relativista, che considerano i pattern come una delle tante opinioni, tranquillamente ignorabili (in special modo quando contraddice le tipologie dominanti militari/industriali). (Silvestri 2009). In questo senso è molto interessante il rapporto che Alexander ebbe con le istituzioni, ovvero l'aspetto burocratico di tutto il processo, infatti, dal momento che il processo costruttivo era radicalmente alternativo alla pratica comune, la novità coinvolgeva anche il sistema di norme e regolamenti all'interno del quale si sarebbe dovuto espletare: Alexander risolse il problema ottenendo il permesso dalle autorità governative non per un progetto de nito, ma per un processo costruttivo speci co.

Invece di chiedere l'autorizzazione alla costruzione presentando

10 Allo scopo di ottenere delle abitazioni degne che funzionino bene e che riescano a esprimere l'unicità di ogni famiglia, ciascuna famiglia è chiamata a utilizzare uno strumento che noi chiamiamo `pattern language' . [traduzione italiana a cura dell'autore].

11 L'aspetto alienante degli edi ci che vengono costruiti è, in n dei conti, la diretta

conseguenza della profonda struttura del loro sistema produttivo; questo aspetto non può essere sostanzialmente migliorato a meno che lo stesso sistema di produzione non venga modi cato alle sue radici [traduzione italiana a cura dell'autore].

Figura 3.6:

CAPITOLO 3.

ARCHITETTURA APERTA

Il volantino distribuito nella cittĂ di Mexicali per pubblicizzare il nuovo

programma di autocostruzione e ricercare famiglie interessate (tratta da Alexander, 1985).

3.2.

ARCHITETTURA APERTA

dei disegni nali, ottenne l'approvazione dalle autorità per l'avviamento di processo edilizio basato sull'uso dei `pattern'.

Rileggere oggi i `pattern' A pattern language has the structure of a network.

(Alexander et al. 1977)

L'eredità di Alexander è piuttosto forte, ciò che sorprende di più del suo lavoro è il fatto che sia riuscito a superare le barriere disciplinari e che il suo `pattern language' sia stato abbracciato anche da altri studiosi, come ad

esempio gli informatici

. Uno degli aspetti più interessanti è forse quello di

aver preconizzato una caratteristica peculiare della società delle reti, ovvero quella che nei capitoli precedenti abbiamo chiamato ricombinazione. Il fatto che la risoluzione di un problema avvenga attraverso la ricombinazione di risposte singole, le quali a loro volta generano esponenzialmente diverse soluzioni, rispecchia il processo di sviluppo del software (e non solo) in molte sue parti.

L'utilizzo di librerie di funzioni che vengono mescolate, modi -

cate e combinate insieme per ottenere nuovi programmi (che non sono altro che soluzioni di problemi speci ci) assomiglia molto all'utilizzo dei `pattern' e alla loro natura. Il fatto poi che dei `pattern' ne venga fatto un utilizzo aperto, collaborativo, in cui sono coinvolti molteplici attori, sembra ricalcare

12 Il linguaggio dei pattern ha la struttura di un network. [traduzione italiana a cura dell'autore].

13 Christopher Alexander is perhaps having a greater impact on computer science than

on architecture. Alexander's Pattern Language is being applied to Object Oriented Programming, and is inspiring innovative techniques that go beyond it. Theoretical structures that he de ned are now recognized as general frameworks in which to link objects in programs together in a co-operative and sequential manner. Already for several years now, the topic of Pattern Languages is established in software, and possesses a rapidly growing bibliography. There is a yearly conference called Pattern Languages of Programming (PLoP). Christopher Alexander was invited to give the keynote address at the 1996 Object Oriented Programming Conference OOPSLA. (Salingaros 1997) trad: Christopher Alxander ha probabilmente avuto più in uenza in campo informatico che in campo architettonico. Il linguaggio dei pattern è stato applicato nella programmazione orientata agli oggetti, e sta ispirando tecniche innovative. La struttura teorica che ha de nita viene ora riconosciuta come un'ossatura principale in cui collegare insieme gli oggetti in maniera cooperativa e sequenziale. Ormai da molti anni il tema del `pattern language' ha un proprio status in campo software, e la letteratura collegata cresce rapidamente. Ogni anno si celebra anche una conferenza chiamata `Il linguaggio dei pattern nella programmazione (PLoP)'. Christopher Alexander è stato invitato a tenere un discorso nel 1996 alla conferenza sulla programmazione orientata agli oggetti (OOPSLA). [traduzione italiana a cura dell'autore].

CAPITOLO 3.

ARCHITETTURA APERTA

letteralmente il processo di sviluppo Open Source come descritto ad esempio da Raymond. Oltre a ciò vi è anche un utilizzo di termini speci ci che torneranno poi in campo informatico, come ad esempio l'utilizzo della parola network prima di Internet, oppure la ripresa del termine `pattern' nella programmazione orientata agli oggetti.

3.2.2 Habraken e i `supports' In un certo senso, e come apparirà più avanti, è molto più importante capire il processo attraverso il quale un'abitazione si crea, piuttosto che comprendere i connotati del suo aspetto esteriore

(Habraken 1974)

Nel 1962 N.J. Habraken , un architetto olandese impiegato presso un centro di ricerca pubblico, il SAR (Foundation for Architects Research) dà alle stampe un libro (che verrà tradotto in inglese solo 10 anni più tardi) dal titolo, nella versione inglese, Supports, an alternative to mass housing. Già dal titolo è facile capire come ci siano delle evidenti assonanze con il lavoro di Alexander, ovvero la ricerca di un'alternativa alla produzione edilizia standardizzata e di massa, considerata dai due alienante e responsabile di esperienze abitative non consone alla condizione umana. Se i due sembrano essere sulla stessa linea d'onda, perlomeno per quanto riguarda i presupposti, arrivano tuttavia a soluzioni radicalmente diverse. La tesi di Habraken è basata sulla de nizione dei `supports' del titolo: elementi che garantirebbero, secondo Habraken, la corretta inclusione dell'utente nale all'interno del processo edilizio. È infatti sua convinzione che accettando il coinvolgimento e l'iniziativa dell'utente, come punto di partenza della soluzione del problema delle abitazioni possiamo incominciare a intravvedere una via di uscita rispetto ai limiti operativi in cui oggi ci imbattiamo.

Ne emergono infatti

possibilità insospettate: sia l'aspetto tecnico che quello umano del problema delle abitazioni possono acquistare nuove prospettive. Non vi sono pressochè limiti alle possibilità che così si aprono: con questa nuova consapevolezza ci si può avviare verso un rinnovato arricchimento dei nostri sistemi di vita. (Habraken 1974, p. 37). I `supports' si con gurano come il punto di partenza di un processo progettuale `aperto', in cui gli utenti compaiono non solo come semplici fruitori, ma anche, e soprattutto, come modellatori del loro nuovo habitat. Agendo all'interno della struttura di sostegno, l'utente nale è in grado di modellare il proprio habitat secondo le sue necessità: La risposta può essere semplice e nello stesso tempo globale. Dobbiamo fare delle costruzioni che non si con gurino come edi ci o come abitazioni per loro stessa natura, ma siano capaci

3.2.

ARCHITETTURA APERTA

di sollevare le abitazioni dal suolo; costruzioni che contengono le abitazioni individuali né più né meno di come una libreria contiene i libri, così da poterle rimuovere e ricollocare separatamente, costruzioni che si sostituiscano al suolo, che forniscano una super cie edi cabile sospesa per aria, che siano permanenti come lo sono le strade. Senza considerare per ora il loro aspetto formale, vorrei chiamare queste costruzioni strutture di sostegno [supports], e ciò per la funzione che ho loro assegnato.

Ogni struttura, quindi, che ci

permetta di costruire abitazioni indipendenti che non siano a livello del suolo, è una struttura di sostegno. Propongo questa de nizione: una struttura di sostegno è una costruzione che ci permette di ottenere abitazioni che possano essere costruite, modi cate e abbattute, indipendentemente una dall'altra. (Habraken 1974, p. 156). All'interno del supporto prende posto `l'in ll': la struttura di supporto rappresenta una responsabilità comune nella produzione di alloggi di massa, mentre l'acronimo `in ll' de nisce il controllo individuale dell'alloggio.

supporto deve essere progettato da tecnici, a cui spetta un compito speci co e una responsabilità:

de nire la distribuzione degli spazi in funzione agli

impianti e alle tecnologie.

Gli utenti potranno modi care la propria unità

abitativa secondo le diverse esigenze. (Solazzo 2009).

Esempi di applicazioni dei supports

Una delle prime applicazioni delle

strutture di supporto fu portata avanti dallo stesso Habraken, il quale nel 1974 sviluppò un quartiere residenziale seguendo i principi di supporto e in ll.

Il progetto Molenvliet a Papendrecht, vicino a Rotterdam, progettato

insieme all'architetto Frans van der Werf è, stando alle parole di Habraken, the rst full blown support/in ll project realized. The project is set up as an urban tissue in which buildings form courtyards from where access to houses is given. Because house units have been designed by users, no two oor plans are alike, as can be seen as the documentary drawing made after completion of the project

(Habraken n.d.).

In seguito alla traduzione dei testi di

Habraken in inglese (non solo Supports ma anche Variations, the Systematic

Design of Supports ) si è sviluppato un certo interesse tra vari ricercatori, il quale ha portato alla costituzione del `CIB W104 Open Building Implemen-

14 Il primo progetto che sviluppa appieno il sistema `support/in ll' mai realizzato. Il progetto è con gurato come un tessuto urbano in cui gli edi ci formano delle corti dalle quali è possibile accedere agli edi ci stessi. Dal momento che le unità abitative sono state disegnate dagli stessi abitanti, nessun alloggio è uguale a un altro, come si può evincere dalla documentazione redatta dopo il completamento del progetto. [traduzione italiana a cura dell'autore].

CAPITOLO 3.

tation'

ARCHITETTURA APERTA

(CIB sta per International Council for Research and Innovation in

Building and Construction).

Quest'ultimo Ă¨ un network internazionale di

ricercatori e professionisti che, ispirati dagli studi di Habraken, si interessano a edi ci di tipo `aperto', de niti `open building'.

Tali ricerche porteranno

a sperimentare il modello `supports/in ll' in diverse aree del mondo, come

ad esempio in Giappone

, dove Ă¨ stato costruito l'edi cio NEXT21 su pro-

getto di Yositika Utida nel 1994:

NEXT21 was constructed as a whole,

but designed in such a way that its various subsystems can be adjusted with improved autonomy. To test this objective, one 5th-story unit has been substantially renovated.

All work was accomplished from within the unit,

without sca olding, minimizing disruption to abutting inhabitants. 90% of the materials removed were successfully redeployed. The project continues to explore new methods for building urban housing, experimental in ll systems, to accommodate varying lifestyles with reduced energy consumption. The second phase of NEXT21 includes renovating other units, including a new group of inhabitants, and continued evaluation of the energy system.

(Kendall 2000) (Figura 3.7). L'impatto sul mondo della produzione architettonica Ă¨ stato decisamente forte: basti pensare ad esempio alle recenti inziative di ELEMENTAL di Alejandro Aravena, dove la costruzione del supporto permette non soltanto di modi care internamente la propria abitazione, ma anche di ampliarla aggiungendo nuovi locali e nuova volumetria (Figura 3.8).

Rileggere oggi i `supports'

La grande forza delle idee di Habraken Ă¨ sta-

ta forse quella di permettere che negli ambienti accademici e professionali si iniziasse a leggere l'edi cio come un sistema aperto, non piĂš legato unicamen-

15 All'indirizzo

web

http://open-building.org/

Ă¨

possibile

consultare

tutti

documenti dei vari convegni organizzati dal CIB W104.

16 GiĂ a partire dal 1980 esisteva in Giappone un programma ministeriale, chiamato

Century Housing System (CHS), sviluppato dal professor Utida, che mirava a prolungare la vita utile degli edi ci proponendo l'adozione obbligatoria di un sistema di tipo `support/in ll' per le nuove costruzioni (Kendall 2000).

17 NEXT21 Ă¨ stato costruito come un unicum, ma progettato di modo che i vari sot-

tosistemi possano essere modi cati in totale autonomia. Per dimostrare questo principio il quinto piano Ă¨ stato completamento ristrutturato.

Tutti i lavori sono stati realizzati

all'interno dell'unitĂ , senza ponteggi, riducendo al minimo disagi per i vicini. Il 90% dei materiali rimossi sono stati rimessi in opera con successo. Il progetto continua a esplorare nuovi metodi per la costruzione di abitazioni urbane e sistemi di tamponamento sperimentali al ne di accogliere diversi stili di vita con un consumo energetico ridotto. La seconda fase del NEXT21 comprende la ristrutturazione di altre unitĂ , coinvolgendo un nuovo gruppo di abitanti, e si Ă¨ continuata la valutazione del sistema energetico. [traduzione italiana a cura dell'autore].

3.2.

ARCHITETTURA APERTA

Figura 3.7:

Immagine dell'edi cio NEXT21 (fonte:

next21.html)

te alla volontĂ dell'architetto

http://open-building.org/ob/

e ai suoi disegni, ma passibile di modi che e

aggiustamenti (o customizzazioni, dall'inglese `custom', su misura). L'approfondimento e lo studio delle teorie di Habraken ha portato anche

18 Ă&#x2C6; qui necessario sottolineare che Habraken non fu il primo a sviluppare tali ipotesi, ma il suo lavoro Ă¨ stato certamente quello quello con piĂš impatto. In realtĂ giĂ Le Corbusier, per il Plan Obus ad Algeri, sviluppato dal 1931 al 1935, aveva ipotizzato che le unitĂ abitative potessero essere indipendenti dalla struttura che le sosteneva: Al livello della produzione minima - quello della singola cellula residenziale - il tema da a rontare Ă¨ il recupero della massima essibilitĂ , intercambiabilitĂ , possibilitĂ di rapido consumo. Nelle maglie delle grandi strutture, costituite da `terrains arti ciels' sovrapposti, Ă¨ concessa la piĂš ampia libertĂ di inserimento di elementi residenziali preformati. Rispetto al pubblico, ciĂ˛ signi ca invito a farsi progettista attivo della cittĂ .

Le Corbusier, in uno schizzo

dimostrativo, giunge no a prevedere la possibilitĂ di inserimento di elementi eccentrici ed eclettici nelle maglie delle strutture sse (Figura 3.9). La `libertĂ ' concessa al pubblico deve spingersi tanto in lĂ da permettere al pubblico stesso - al proletariato nel caso della serpentina, che si snoda al cospetto del mare e all'alta borghesia sulle colline di Fortl'Empereur - l'esplicazione del suo `cattivo gusto'. L'architettura come atto pedagogico e strumento di integrazione collettiva, dunque (Tafuri 2007, p. 121).

CAPITOLO 3.

ARCHITETTURA APERTA

Figura 3.8: Il processo evolutivo posto in essere dai progetti ELEMENTAL: nella parte alta dell'immagine gli edi ci consegnati agli abitanti della Quinta Monroy, nella parte bassa, gli edi ci come si presentano dopo gli ampliamenti da parte degli utenti (fonte:

http://www.elementalchile.cl/proyecto/quinta-monroy/).

3.2.

ARCHITETTURA APERTA

Figura 3.9: Il disegno di Le Corbusier per il Plan Obus ad Algeri. Si intravedono, inserite nella struttura, le varie unità abitative che virano dallo stile moderno, al moresco, al gotico, al romanico. L'immagine è tratta dal tezo volume dell'Oeuvre complète di Le Corbusier (1953).

a quello che può forse essere de nito il primo tentativo di introduzione delle teorie legate al mondo dell'Open Source nel mondo dell'edilizia e dell'architettura. Presso il MIT un gruppo di ricercatori (K. Larson, S. Intille, T. J. McLeish, J. Beaudin and R. E. Williams) ha portato avanti, nei primi anni 2000, un progetto di ricerca intitolato Open Source Building. Questo progetto di ricerca si proponeva di brings together aspects of open building as developed by John Habraken, with open source strategies, as found in the software and electronics industries.

(Larson, Intille, McLeish, Beaudin &

Williams 2004). Il progetto prevedeva diverse fasi. La prima era uno studio dettagliato di un nuovo sistema di supporto, orientato principalmente alla risoluzione delle problematiche relative alla realizzazione di un e cace sistema di alloggiamento degli impianti. La seconda parte era focalizzata sulla realizzazione di sistema di interazione tra utente e alloggio, di modo che il primo fosse in grado, attraverso l'utilizzo di schermi interattivi, di simulare diverse varianti del proprio alloggio (basato sul precedente sistema di supporto) e di averne una visualizzazione e cace. La terza componente, che rimaneva (e continua a rimanere, giacché non ulteriormente sviluppata) ancora in divenire, era quella che nalmente introduceva il concetto di Open Source nell'edilizia, preconizzando una alleanza tra produttori, costruttori e progettisti: We propose that industry and academic researchers come together to create a high-level `systems architecture' that allows for integrated research leading to industry agreement on design principles (resulting in industry standards). To this end, we have formed the Open Source Building Alliance (OSBA). The

19 di unire le caratteristiche `dell'open building', così come de nite da Habraken, con la strategia open source, sviluppatasi nelle industrie del software e dell'elettronica. [traduzione italiana a cura dell'autore].

CAPITOLO 3.

ARCHITETTURA APERTA

goal of OSBA is to trigger an explosion of creative activity resulting in highperformance, cost-e ective environments by: 1) standardising approaches to a building `chassis' and the interfaces between elements, 2) developing an agile methodology for unlimited variations of the elements that people see, touch, and interact with or `infull'.

(Larson et al. 2004). Tale iniziativa

sembra non aver avuto seguito. Alla luce di quanto successo a partire dal 2006 in poi, ovvero con l'esplosione del web 2.0 e la pervasivitĂ dei network e dei loro servizi, sembra opportuno rivedere il possibile signi cato odierno dei supporti. Quando Habraken parla di supporti, ci si immagina degli enormi scheletri pronti a ospitare nuove famiglie e accoglienti appartamenti. Alla luce della svolta computazionale dell'architettura sembra necessario rileggere i `supports' sia come un supporto sico - strutturale, ma anche come un supporto informazionale, cioĂ¨ come un supporto cognitivo all'interno del quale sviluppare progetti e processi architettonici. La rilettura odierna che puĂ˛ essere fatta dei supporti (e in un certo senso anche dei pattern) Ă¨ che siano molto piĂš utili come base di una organizzazione cognitiva rivolta all'utilizzo e gestione dello spazio, piuttosto che strumenti di de nizione dello spazio.

3.2.3 Friedman e il ` atwriter' Un'altra gura interessante del periodo, sicuramente da prendere in considerazione, Ă¨ quella di Yona Friedman, architetto ungherese naturalizzato francese che ha concentrato parte dei suoi studi proprio sulla partecipazione e sull'auto-organizzazione. Uno degli aspetti piĂš interessanti del suo lavoro Ă¨ quello di essere sorprendentemente pre-computazionale, nel senso che le applicazioni matematiche che lui propone come accompagnamento al processo partecipativo anticipano quello che poi si sarebbe sviluppato attraverso la di usione dei computer. Le visioni di Friedman, oltre a essere alla base di ricerche visionarie, come ad esempio quelle degli Archigram, sono anche state adottate da altri ricercatori, ad esempio da Nicholas Negroponte presso il MIT. Procedendo per gradi conviene prendere in considerazione il lavoro

20 Proponiamo che l'industria e i ricercatori accademici si uniscano al ne di creare una architettura sistemica di alto livello, che consenta di ottenere degli accordi industriali su principi progettuali (con conseguenti standard di settore). A questo scopo abbiamo formato la Open Source Building Alliance (OSBA). L'obiettivo dell'OSBA Ă¨ quello di innescare un processo creativo che porti ad alte prestazioni e ambienti convenienti, agendo 1) sulla standardizzazione degli approcci al telaio strutturale e alle interfacce tra gli elementi 2) sullo sviluppo di una metodologia agile che permetta in nite variazioni degli elementi che l'utente puĂ˛ vedere, toccare, con cui puĂ˛ interagire. [traduzione italiana a cura dell'autore].

3.2.

ARCHITETTURA APERTA

di Friedman partendo dagli albori della sua attivitĂ .

Interessatosi inizial-

mente all'architettura mobile, Friedman fonda la GEAM (Groupe d'Ă&#x2030;tudes d'Architecture Mobile) immediatamente dopo aver partecipato al CIAM 10 (tenutosi a Dubrovnik nel 1956).

Entra in contatto con molti membri del

Team X e, negli anni in cui risiede in Europa, entra in contatto con Habraken, il quale si era occupato in precedenza di architettura mobile. Il corpus principale del suo lavoro Ă¨ contenuto nel libro Per una architettura scienti -

ca, edito nel 1972 ma in lavorazione giĂ a partire dal 1964. In esso Friedman presenta una sua proposta in grado di favorire l'auto-organizzazione dello spazio costruito da parte degli utenti: Io ho chiamato ` atwriter' una macchina, grazie alla quale ogni futuro abitante di una cittĂ puĂ˛ indicare le sue preferenze personali riguardo al suo futuro appartamento, e con l'aiuto di `simboli' che visualizzano i di erenti elementi della sua decisione in modo tale che questa decisione possa essere compresa tanto dal direttore dei lavori quanto da ciascun abitante vicino. In altre parole, questa macchina `contiene' un elenco di qualche milione di piani di appartamenti possibili, sa calcolare le `avvertenze' riguardo alle conseguenze caratteristiche implicate dall'eventuale modo di utilizzazione di ciascun futuro abitante (utente) individuale, e in ne puĂ˛ calcolare se la sistemazione scelta da un futuro abitante rischia o no di disturbare gli altri abitanti. (Friedman 1972, p. 80). Ă&#x2C6; proprio in queste parole che si evince la capacitĂ di Friedman di intravedere le potenzialitĂ dei calcolatori di allora

e di utilizzare gli stessi strumenti logici che

verranno poi usati nella programmazione. Attraverso la costruzione di liste che contengono tutte le possibilitĂ per regolare il taglio degli alloggi, e la consultazione di queste ultime da parte dell'utente sotto forma di gra , si ottiene la soluzione ottimale per l'utente stesso, il quale andrĂ a posizionare il suo alloggio all'interno di una appropriata infrastruttura: Parallellamente al `Flatwriter' Ă¨ prevista la realizzazione di una `infrastruttura', cioĂ¨ di una ossatura vuota a livelli multipli.

In questa ossatura Ă¨ contenuta la rete di

viabilitĂ : acqua, gas, elettricitĂ , fogne ecc. (Friedman 1972, p. 80). Il ruolo dell'architetto diviene dunque quello di costruttore di `infrastrutture' capaci di accogliere gli alloggi prescelti oltre che di organizzatore teorico del sistema.

Il computer come traduttore

Vi Ă¨ dunque un aspetto che puĂ˛ essere

letto come una discendenza delle idee di Habraken (il support, chiamato da Friedman infrastruttura) e una parte invece piĂš complessa (ma piĂš e cacemente esposta e ampliata) che potrebbe essere invece legata ai lavori di

21 Si fa qui riferimento ai vecchi mainframe; bisogna infatti tenere conto che il libro Ă¨ uscito nel 1972 ma Friedman comincia a parlare del ` atwriter' dal 1967, il primo pc risale al 1976 e per la nascita di Internet dobbiamo aspettare il 1983.

CAPITOLO 3.

ARCHITETTURA APERTA

Alexander (Note sulla sintesi della forma, non era ancora uscito A pattern

language ), ovvero quel metodo che potremmo chiamare pre-computazionale di de nire forme e spazi, il quale procede attraverso operazioni logiche basate su bisogni e necessità reali. Friedman esegue un'interessante sintesi compiendo un passo in avanti fondamentale, ovvero introduce un elemento in più nel discorso, il ` atwriter', una macchina. Non sorprende dunque che le idee di Friedman siano state riprese poco tempo dopo presso il MIT nel gruppo di ricerca Architecture Machine Group capitanato da Nicholas Negroponte. Proprio in un libro di Negroponte del 1975 (Soft architectural machine ) Friedman cura l'introduzione al capitolo Computer-Aided Participatory Design. In questo scritto Firedman de nisce, tra le possibile funzioni del computer, quella di translator, as the provisory interface beetween the future user and the object to be designed (which will be part of the real world) and beetween this object and another part of the real world that comprises the `other' human beings who might have some relations with the designed object.

(Friedman 1975). Tutto il lavoro dell'Architecture Machine Group si orienterà sulle interfacce uomo-computer, da cui discenderanno il CAD e gli schermi interattivi di cui si è accennato parlando dell'OSBA. È interessante rileggere Friedman anche per le conclusioni a cui era arrivato: the most interesting research theme open to our generation in the eld of participatory design (computer-aided or not) - design meaning here constructive imagination of physical or nonphysical objects (for example, behavioral ones, like politics) would be to investigate the possibility of paternalist-nonpaternalist scheme, in other words, whether or not machine could be conceived wherein both the intelligent observer (the future user) and the real world (the object of the design) would mutually learn about each other. I think that nearly all research people today are on this track, consciously or not.

(Friedman 1975).

Proprio in quel would mutually learn about each other sembra che si sintetizzi il seme dell'open design dove, attraverso la comunità, utente e oggetto si scambiano mutualmente informazioni.

22 `taduttore', come interfaccia provvisoria tra il futuro utente e l'oggetto che deve essere progettato (che diverrà parte del mondo reale) e tra questo oggetto e un'altra parte del mondo reale, che comprende tutti gli altri esseri umani che entrano in qualche modo in contatto con l'oggetto progettato. [traduzione italiana a cura dell'autore].

23 Il tema di ricerca più interessante per la nostra generazione nel campo della proget-

tazione partecipata (attraverso l'uso del computer o meno) - in questo caso progettazione signi ca immaginazione costruttiva di oggetti sici o no sici (per esempio di comportamenti, come la politica) sarebbe quello di investigare le possibilità dell'approccio paternalistico o non paternalistico, o, in altre parole, che il ` atwriter' possa essere sviluppato o meno, che il futuro utente e l'oggetto della progettazione possano mutualmente imparare l'uno dall'altro.

Penso che tutti i ricercatori di oggi stiano lavorando su questo tema,

consciamente o meno. [traduzione italiana cura dell'autore].

3.2.

ARCHITETTURA APERTA

3.2.4 Il metodo Segal Oggi l'architettura si sforza di ricondurre al suo centro i problemi dell'abitare, del costruire luoghi. L'atto dell'abitare, l'idea dell'abitare come verbo, il ruolo dell'architetto come enabler - come qualcuno cioĂ¨ che aiuta a realizzare questo bisogno elementare che Ă¨ l'attivitĂ di abitare, di 'arrivare a casa', di appropriarsi il suo spazio: sono questi i i ni che Walter Segal ha perseguito senza clamore, con il suo lavoro, per oltre mezzo secolo.

(McKean 1986)

Altro interessante lavoro da analizzare Ă¨ quello svolto da Walter Segal in Inghilterra tra gli anni 70 e 80 del ventesimo secolo.

La sua attivitĂ lo

ha visto attivo perlopiĂš nella costruzione di abitazioni (o complessi di abitazioni) pubbliche a basso costo realizzate attraverso l'utilizzo di un metodo di autocostruzione piĂš tardi denominato Metodo Segal. Caratterizzato dalla semplicitĂ costruttiva e modulare (Figura 3.10), il Metodo Segal rientra a pieno titolo all'interno di quelle esperienze di partecipazione mediata dalla tecnologia viste in precedenza.

Tuttavia, a di erenza dei casi precedenti,

l'apparato teorico Ă¨ piuttosto scarno, mentre la pratica e la costruzione sono le protagoniste assolute e costituiscono l'anima del pensiero di Segal: A lui interessava un modo di costruire comprensibile, che si potesse capire e quindi prevedere, calcolare. Non c'Ă¨ complicazione nella carpenteria comprensibile, ben calcolata , diceva piĂš tardi. (McKean 1986) Basato sull'utilizzo di strutture a telaio in legno di semplice e immediata costruzione, il Metodo Segal non introduce unicamente un metodo costruttivo, ma si pone anche l'obiettivo di riformare il processo edilizio, tentando di cambiarne gli attributi: ...dopo anni e anni di pastoie burocratiche, intorno all'80 potĂŠ cominciare ad aiutare gli iscritti alla lista d'attesa comunale a costruirsi la propria casa.

Per fare questo era necessario cambiare sia il processo costruttivo che

il processo dell'abitare. Segal odiava l'appaltatore - l'impresa che si mette letteralmente di mezzo tra il progettista e l'artigiano [...]

E odiava l'idea

di quartieri costruiti dagli enti municipali per gli alloggi.

Per le case con

struttura in legno degli ultimi anni '60 aveva lavorato direttamente con un capo carpentiere che rispettava moltissimo. Per rivitalizzare tutto il campo dell'edilizia e dell'architettura , diceva intorno al '75, basterebbe rivolgersi ai carpentieri . Ma poi vennero gli autocostruttori, prima pochi isolati e poi la marea di Lewisham che sommerse l'immagine dell'inquilino patrocinato dall'ente locale. Ora, pur progettando edilizia pubblica, Segal lavorava per e con individui reali, e le case erano frutto della loro azione. (McKean 1986). Il metodo Segal Ă¨ interessante per alcuni motivi: il primo Ă¨ che Ă¨ basato sulla modularitĂ , su una semplicitĂ di base e su una banalitĂ di operazioni

CAPITOLO 3.

ARCHITETTURA APERTA

Figura 3.10: Schema assonometrico di una casa a Lewinsham progettata da Segal nel 1984. Da sinistra a destra, dall'alto verso il basso, le varie fasi di costruzione: la realizzazione delle fondazioni, la posa dei telai lignei principali, la realizzazione del tetto e delle strutture secondarie, la posa dei tamponamenti esterni (fonte:

brakkablog/The-Segal-Method).

http://cargocollective.com/

piuttosto notevoli. Ciò non signi ca che i risultati siano semplici o banali, anzi, il contrario. Attraverso l'utilizzo di strutture modulari e operazioni costruttive ripetitive e facili da porre in opera, è possibile ottenere costruzioni anche complesse, solide sotto ogni punto di vista e piuttosto gradevoli. Il secondo motivo è che, proprio grazie a questa semplicità su cui si basa, l'intero processo risulta essere facilmente accessibile e trasmissibile. Sembra infatti di cile pensare che siano stati costruiti interi quartieri da autocostruttori già quali cati: il metodo Segal non è solo uno strumento di applicazione tecnologica, ma uno strumento di `empowerment', un traduttore bidirezionale tra utente e oggetto, strumento che ovviamente diventa oggetto di progettazione da parte dell'architetto.

3.2.

ARCHITETTURA APERTA

La modularità e la semplicità che sta alla base del metodo Segal ha anche permesso di farne oggetto di alcuni dei primi esperimenti di costruzione di interfacce di progettazione per utenti non esperti, al ne di sviluppare strumenti interattivi di coinvolgimento degli utenti nel processo progettuale. John Frazer, collaborando con Segal, ha comiciato a svilupparne alcuni all'inzio delgi anni Ottanta

, e i risultati ottenuti sono molto vicini all'idea

di traduttore (` atwriter') che aveva avuto Friedman (Figura 3.11).

Figura 3.11: L'immagine del Self-Builder Model, poi diventanto Segal Model, sviluppato da John Frazer. Si può notare la presenza dei pannelli di tamponamento e la griglia di base su cui essi possono essere disposti dall'utente, generando nuove dispozioni interne della casa autocostruita. Le regole costruttive e gli output del Self-Bulider Model guidano l'utente nella de nizione di una pianta ottimale. L'immagine è tratta da Frazer (1982).

24 Segal had developed a timber-frame technique for self-homebuilders but had found that the users encountered di culty when it came to selfdesigning their homes. The tangible input tool that was developed, The Self-Builder Model, enabled easy home design for users without any knowledge or experience of either computers or architecture trad. Segal aveva sviluppato una tecnica basata su telai lignei per l'autocostruzione, ma aveva in segutio notato che gli utenti avevano delle di coltà ad auto-progettare le loro case. Lo strumento tangibile di immissione dati, il Self Builder Model, permetteva facilmente agli utenti di de nire il layout della propria casa, senza che fosse necessaria alcuna conoscenza speci ca circa i computer o l'architettura. [traduzione italiana a cura dell'autore]. (Sutphen, Ehud Sharlin, Watson & Frazer 2000)

Capitolo 4 Architettura Open Source 4.1

Il dibattito contemporaneo

Nel capitolo precedente sono state analizzate alcune esperienze del secolo XX il cui lo conduttore Ă¨ stato quello di rivedere il processo architettonico (alla luce della di usione del mass-housing) e di proporre delle strade per il cambiamento. Tutti gli esempi discussi si sono concentrati su di un aspetto in particolare: l'inclusione dell'utente nale all'interno del processo produttivo. Nella prima parte di questa tesi si Ă¨ visto come nel mondo dell'informatica (ma non solo nel mondo dell'informatica), in seguito alla enorme di usione delle tecnologie digitali (i personal computer principalmente) e di Internet, questo tipo di approccio sia ormai una realtĂ consolidata che si attua attraverso fenomeni quali l'Open Source per il software o l'open hardware e l'open design nel campo della produzione di oggetti. In questo capitolo si vedrĂ come anche nel mondo dell'architettura l'ascesa dell'Open Source abbia contribuito a generare interessanti fenomeni innovativi, e come tali fenomeni siano indissolubilmente legati sia alle esperienze architettoniche pregresse che al mondo dell'open design. Prima di approfondire i casi studio che verranno trattati, Ă¨ perĂ˛ necessario ripercorrere brevemente i passi che hanno contribuito allo sviluppo di un'idea di analogia tra Open Source e architettura, ovvero tutto quel corpus di scritti e altri documenti che hanno contribuito allo sviluppo dell'Architettura Open Source.

4.1.1 Primi contributi all'Architettura Open Source Per quanto ci riguarda l'Open Source entra nel dibattito architettonico nei primi anni 2000 con la pubblicazione di un numero monogra co della rivista olandese Archis (il n.3 del 2003), all'interno della quale si iniziava a paventare la possibilitĂ che l'Open Source potesse essere un modello organizzativo

CAPITOLO 4.

ARCHITETTURA OPEN SOURCE

valido anche per lo sviluppo collettivo di soluzioni spaziali legate all'abitazione, alla mobilitĂ , agli spazi verdi e al rinnovo urbano (Figura 4.1). Bisogna tenere conto che in Olanda, come in altri paesi del Nord Europa, le iniziative partecipate sono una costante di molti sviluppi urbani; inoltre giĂ dagli anni Sessanta vi erano diverse teorie ed esperienze che puntavano sulla inclusione del fruitore all'interno del processo edilizio. In uno degli articoli del numero di Archis citato in precedenza, numero monogra co dedicato all'Open Source, l'autore Dennis Kaspori prova a delineare i caratteri che l'Architettura Open Source potrebbe avere. Kaspori parte da due elementi principali: da un lato il movimento Open Source, dall'altro quella che lui, riprendendo quanto scrive Nicolas Bourriaud nel suo libro Postproduction del 2002, chiama postproduzione, ovvero il processo attraverso cui art has developed a practice in which new meanings and ideas are generated within a process of `cultural recycling'.

The recycling, repositioning and reorientation of existing ideas

lead to new ideas (Kaspori 2003). Partendo da questi due concetti chiave, Kaspori individua un aspetto comune: la ricombinazione, resa possibile da un regime di diritto d'autore di erente dal copyright, nel caso del software il copyleft. Queste considerazioni lo portano (siamo sempre nel 2003) a dire che open source provides an organization model for the collective development of solutions for spatial issues involving housing, mobility, greenspace, urban renewal and so on. These are all complex issues that presuppose an interdisciplinary approach; in fact they can only be solved with cooperation. Open source presupposes that these ideas are disclosed and made available to others, who in turn can improve on them.

In this way, design changes

from a one-o action into a kind of evolutionary process. (Kaspori 2003). Kaspori Ă¨ dunque uno dei primi (se non il primo) a dichiarare che l'Open Source potrebbe, per la sua stessa natura, essere uno strumento in grado di aiutare comunitĂ e architetti a progettare le trasformazioni dell'ambiente costruito.

Questa sorta di dichiarazione non viene perĂ˛ accompagnata da

esempi pratici o elementi programmatici. Come giĂ era accaduto per l'open design, le parole di Kaspori non hanno un e etto immediato, poichĂŠ che non

1 l'arte ha sviluppato una pratica per la quale le nuove idee e concetti sono sviluppati attraverso un processo di `riciclo culturale'. Il riciclo, il riposizionamento e l'orientamento delle idee esistenti porta alla formazione di nuove idee. [traduzione italiana a cura dell'autore].

2 l'open source fornisce un modello organizzativo per lo sviluppo collettivo di soluzioni

spaziali che coinvolgono l'housing, la mobilitĂ , gli spazi verdi, il rinnovo urbano e cosĂŹ via. Queste sono tutte questioni complesse che presuppongono un approccio multidisciplinare, che possono essere risolte soltanto attraverso la cooperazione. L'open Source presuppone che le idee siano aperte e distribuiti agli altri, che in cambio le sviluppano.

In questo

modo la progettazione passa da essere una risposta caso per caso a diventare una specie di processo evolutivo. [traduzione italiana a cura dell'autore].

4.1.

IL DIBATTITO CONTEMPORANEO

Figura 4.1: La copertina del numero 3 del 2003 della rivista olandese Archis (fonte:

//archis.org/).

http:

CAPITOLO 4.

ARCHITETTURA OPEN SOURCE

si era ancora veri cata la convergenza tecnologica che ne avrebbe favorito uno sviluppo immediato, anche se sembrava plausibile pensare che la direzione dello sviluppo dell'architettura e dell'urbanistica potesse abbracciare le tematiche proposte dal movimento Open Source. In un certo senso si potrebbe dire che Kaspori fosse cosciente dei limiti all'interno dei quali si muoveva e sviluppava la sua teoria:

Open source would seem to be an attractive

model for an architectural practice wishing to revive its pro-active role in spatial issues. Cooperation and the exchange of ideas give rise to a learning organization that is able to evolve by reacting alertly to change. This sounds easier than it is.

As suggested earlier, the idea of a collaborative practice

presupposes a complete reversal of the existing organizational model of a discipline that is very keen on its autonomy and the concept of copyright. [...] Open source is not a model to be developed and rolled out on a large scale. It must have a chance to evolve gradually. It entails an experimental process of adjustment.

Open source is a process of growing awareness, a

turn-around in thinking about the fundamental organizational principles of architectural practice. It is important to depict architecture not only as an aesthetic object or showpiece, but also as a learning process and a subject

for discussion. (Kaspori 2003). Le idee di Kaspori verranno portate avanti in un blog nello stesso anno

, ma questo non ebbe particolare seguito e al

momento non Ă¨ piĂš raggiungibile.

All'incirca nello stesso periodo (nel 2002) Usman Haque scrive un articoall'interno del quale il ragionamento si sviluppa principalmente attorno

al ruolo del fruitore e a quello del progettista: A truly open source architecture does not exist without people to inhabit, occupy, perceive, interact or

3 L'open source sembrerebbe essere un modello interessante per una pratica architettonica che intenda rilanciare il suo ruolo proattivo nelle questioni spaziali. La cooperazione e lo scambio di idee danno vita a una `learning organization' capaci di svilupparsi reagendo al cambiamento. Sembra piĂš semplice di quello che e ettivamente Ă¨. L'idea di una pratica collaborativa presuppone una completa inversione del modello organizzativo esistente di una disciplina che Ă¨ molto conservatrice per quanto riguarda la sua autonomia e il concetto di copyright.

[...]

L'open source non Ă¨ un modello che puĂ˛ essere srotolato sulla

grande scala. Deve avere la possibilitĂ di evolversi gradualmente. Comporta un periodo di sperimentazione e regolazione. L'open source Ă¨ un processo di crescente consapevolezza, un'inversione di pensiero dei principi organizzativi fondamentali della pratica architettonica . Ă&#x2C6; importante descrivere l'architettura non solo come oggetto estetico o pezzo forte, ma anche come un processo di apprendimento e oggetto di discussione . [traduzione italiana a cura dell'autore].

4 http://www.suite75.net/blog/maze/ 5 L'articolo in questione, dal titolo

Hardspace, softspace and the possibilities of Open

Source Architecture venne poi presentato insieme all'articolo di Kaspori nel 2004 al RAM5:

Open Source Media Architecture, un congresso organizzato dal Ram: Re-Approaching New Media workshop, una rete di istituti di ricerca scandinavi.

4.1.

IL DIBATTITO CONTEMPORANEO

converse with it. The resulting spaces don't merely enable people to develop their own ways of responding, they are actually enriched by them doing so. As people become architects of their own spaces (through their use) or developers of their own interfaces, the words àrchitecture` and ìnterface' cease to be nouns: instead they become verbs. Such an architecture is explicitly dynamic, a shift that opens up a wealth of poetic possibilities for designers of òpen source' space.

(Haque 2002). Nonostante si sia ancora lontani da una

possibile applicazione pratica, Haque delinea giĂ abbastanza chiaramente alcuni dei caratteri che, come si vedrĂ in seguito, sono peculiari di questo tipo di attivitĂ : There are several key features to an open source architecture: 1. Designer-participants: where those who participate are also those who design the system. 2. 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 di erent, versions of the game. 3. Choreographies for openness: group instructions that are interpreted and modi ed as necessary by participants, individually or collectively. 4. Re-appropriation: where existing spaces, objects or actions are both fuel and catalysts for further creativity. 5. Capacity for sharing design problems: each person has di erent skills and often a problem requires a solution that can only be provided by another.

(Haque 2002). Alcune proposizioni sembrano ricalcare le idee di Fried-

man (il ` atwriter' come `control system'), mentre la visione del `designer

6 Un'architettura veramente open source non esiste senza le persone che la abitano, che la occupano, che la percepiscono, che vi interagiscono e vi dialogano. Gli spazi risultanti non si limitano a consentire alle persone di sviluppare la propria visione, ma sono in realtĂ arricchiti da questo processo. CosĂŹ come le persone diventano arte ci del loro spazi (attraverso il loro utilizzo) o gli sviluppatori delle proprie interfacce , le parole `architettura' e `interfaccia' smettono di esser sostantivi:

diventano verbi .

Una tale architettura Ă¨

esplicitamente dinamica, un cambiamento che apre a una ricchezza di possibilitĂ poetiche per i progettisti di spazi `open source'. [traduzione italiana a cura dell'autore].

7 L'architettura open source ha diverse caratteristiche chiave: 1) Designer - parteci-

panti: coloro che partecipano sono anche quelli che progettano il sistema 2) Un sistema di controllo che permette al singolo di esserne parte al ne di espandere tale struttura: un esempio puĂ˛ essere trovato nei videogames che forniscono moduli per gli utenti che permettono di creare la propria, a volte sorprendentemente diversa, versione del gioco 3) Coreogra e di apertura: istruzioni di gruppo che vengono interpretate e, se necessario, modi cate dai partecipanti , individualmente o collettivamente. 4) Riappropriazione: dove gli spazi esistenti , gli oggetti o le azioni fungono sia da carburante che da catalizzatore per ulteriore creativitĂ 5) CapacitĂ di condividere i problemi progettuali: ogni persona ha competenze diverse e spesso un problema richiede una soluzione che puĂ˛ essere fornita solo da un altro. [traduzione italiana a cura dell'autore].

CAPITOLO 4.

ARCHITETTURA OPEN SOURCE

participant' sembra essere un l rouge che accompagna quasi tutte le esperienze viste nora. La visione di Haque viene arricchita anche da alcune idee circa il tipo di processo che potrebbe e ettivamente innescare un cambiamento: In the immediate future, open source architecture would require two distinct steps.

First would be to develop infrastructures that enable `non-

professional' designers to participate more closely in design and construction process.

In some senses, this is already occurring, as the self-build trend

shows. However, `professional' architects can do much more to facilitate the transition.[...] Second would be to apply knowledge of space design to the formulation of a framework within which other people can consciously design spaces. In this capacity, architects would encourage recognition of the distinction between `good' design and `bad' design, if that can be said to exist.

(Haque 2002).

Sebbene la visione di Haque (come si evince dal titolo del contributo:

Hardspace, Softspace And The Possibilities Of Open Source Architecture ) sembra essere piĂš orientata verso una visione piĂš vicina all'open building, ovvero allo spazio open source piĂš che al processo Open Source, le osservazioni che vengono proposte risultano essere molto pertinenti. Non a caso una delle sperimentazioni e applicazioni di rilievo di una possibile Architettura Open Source si occupa proprio di a rontare questi temi: l'Open Architecture Network, sviluppato a partire dal 2006. Cameron Sinclair, uno dei fondatori di Architecture for Humanity (AfH), annunciĂ˛, durante la conferenza di premiazione del TED Prize, che avrebbe usato parte dei soldi del premio per sviluppare una piattaforma ispirata ai principi dell'Open Source e orientata principalmente ad a rontare le problematiche relativa all'architettura nei paesi in via sviluppo e all'architettura per l'emergenza (Sinclair 2006). AfH era stata fondato dallo stesso Sinclair (con Kate Stohr) nel 1999 e nel 2006 godeva giĂ di una certa fama; si occupava di gestire e promuovere progetti in tutti i continenti. La piattaforma, chiamata Open Architecture Network, veniva presentata come un repository (un archivio digitale accessibile online) all'interno del quale tutti i progetti erano liberamente accessibili e nella quale si sarebbe potuto principiare una enorme rete collaborativa nella quale

8 Nell'immediato futuro, l'architettura open source richiederĂ due fasi distinte.

primo luogo bisognerĂ sviluppare delle infrastrutture in grado di permettere ai `non professionisti' di partecipare piĂš attivamente ai processi progettuali e costruttivi. In un certo senso ciĂ˛ sta giĂ avvenendo, come dimostrano le iniziative di autocostruzione. In ogni caso i professionisti possono fare molto per facilitare questo processo. In secondo luogo sarĂ necessario utilizzare gli strumenti che si utilizzano normalmente nella progettazione architettonica per de nire delle piattaforme attraverso le quali gli individui siano in grado di progettare coscientemente degli spazi. In questo caso gli architetti dovranno instillare la capacitĂ di distinguere tra una buona e una cattiva architettura, sempre che questa distinzione realmente esista. [traduzione italiana a cura dell'autore].

4.1.

IL DIBATTITO CONTEMPORANEO

alcuni partecipanti (addetti ai lavori come architetti e ingegneri) avrebbero potuto sviluppare e modi care progetti architettonici, mentre gli altri partecipanti (le comunitĂ e le organizzazioni che agiscono sul territorio) avrebbero potuto trovare risposte ai loro problemi. Lo scambio libero dei progetti era garantito dall'utilizzo di speci che licenze Creative Commons. Il lancio della piattaforma contribuĂŹ a coniare il termine Architettura Open Source, anche grazie all'interessamento di riviste come Wired che si interessarono all'iniziativa (Zjawinski 2007). AldilĂ del funzionamento della piattaforma, che verrĂ analizzato in seguito, nel caso dell'Open Architecture Network fu la prima volta che si parlĂ˛ di licenza copyleft applicata a un progetto di architettura, aprendo cosĂŹ un dibattito sulla natura dell'autorialitĂ del progettista.

4.1.2 Il dibattito attuale Ă&#x2C6; perĂ˛ nel 2011 che le riviste di architettura si interessano alle esperienze di Architettura Open Source.

Nel giugno di quell'anno esce un numero

pressochĂ¨ monogra co di Domus (il numero 948 del giugno 2011) all'interno del quale vengono presentate delle iniziative interessanti (Figura 4.2). L'editoriale, scritto a piĂš mani sotto la direzione di Carlo Ratti (tra i contributors vi erano anche Habraken, Negroponte e Sterling), prova a dare una de nizione del fenomeno in atto: Cucinare Ă¨ spesso considerato una delle prime forme di open source: l'architettura vernacolare, condividendo in modo libero l'ottimizzazione delle tecnologie edilizie e producendo ricette per gli edi ci di tutti i giorni, Ă¨ un'altra forma antica di cultura open source a bassa tecnologia.

Una forma contemporanea di architettura vernacolare

open source Ă¨ quella praticata dall'Open Architecture Network fondato da Architecture for Humanity, la quale ha sostituito i vincoli tradizionali dei diritti d'autore con delle licenze `Creative Commons', dando cosĂŹ libero accesso alle informazioni progettuali. In modo piĂš ampio, OSArc si basa su una piattaforma digitale comune e sugli spazi condivisi del World Wide Web per favorire collaborazioni istantanee aldilĂ dei consueti regimi di competizione e di pro tto.

Gli strumenti tradizionali della progettazione architettonica,

disegni, piante eccetera, sono integrati e via via sostituiti da applicazioni software interattive che si avvalgono di dati relazionali e della connettivitĂ parametrica in rete. OSArc non riguarda solamente la produzione; il modo in cui un determinato progetto Ă¨ percepito, da parte della critica, del pubblico, della clientela e dei ricercatori, spesso puĂ˛ fare parte del processo progettuale, creando una sorta di circolo critico che puĂ˛ far decollare, o a ondare, un'idea, e in de nitiva puĂ˛ entrare a far parte integrante dello stesso processo.

OSArc sostituisce l'architettura statica, fatta di forme geometriche,

con dei processi dinamici e partecipativi, network e sistemi informatici.

CAPITOLO 4.

ARCHITETTURA OPEN SOURCE

Figura 4.2: La copertina del numero 3 del giugno 2011 della rivista Domus (fonte:

//www.domusweb.it/).

http:

suoi sostenitori riconoscono una chiara dominanza del codice sulla materia, dei sistemi relazionali sulla composizione architettonica, dei network sulle griglie strutturali, della capacità di adattarsi sulla statica, della vita stessa rispetto alla piani cazione. Il suo ne è di trasformare l'architettura da un meccanismo produttivo immutabile, dall'alto verso il basso, in un sistema trasparente ed ecologico, inclusivo, dal basso verso l'alto anche se comprende ancora dei meccanismi dall'alto verso il basso. OSArc si appoggia sia sui dilettanti; sia sull'esperienza dei professionisti, sia sulla genialità delle masse, sia su quella individuale, erodendo la distinzione binaria tra l'autore e la sua audience. Così come i software sociali, OSArc riconosce il ruolo fondamentale di tutti i partecipanti a ogni fase progettuale, dal committente ad altri tipi di comunità, dai progettisti agli utenti nali, e cerca di sfruttare al meglio l'incredibile capacità dei network di proporzionare i sistemi in modo e cace. Custodendo i principi dell'accesso libero e della partecipazione pubblica, OSArc è tipicamente democratica, anche se bisogna dire che esistono varie sfaccettature politiche che vanno considerate, dal subdolo autoritarismo al consensualismo comunitario. (Ratti, Antonelli, Bly, Dietrich, Grima, Hill, Habraken, Haw, Maeda, Negroponte, Obrist, Reas, Santambrogio, Somajni,

4.1.

IL DIBATTITO CONTEMPORANEO

Sterling & Shepard 2011a). Questa prima de nizione, corredata da alcuni articoli contenenti la presentazione di casi studio, seppur vaga e onnicomprensiva (dal design all'urbanistica passando per gra ca e edilizia) e poco collegata alla de nizione di

Open Source che fa l'Open Source Iniziative , ha tuttavia il merito di essere un primo tentativo di sistematizzazione di esperienze variegate ed eterogenee che tra loro condividono un forte legame con la rete e con le comunitĂ virtuali, e un esplicito richiamo al movimento Open Source, aprendo il dibattito a nuovi argomenti di discussione.

L'articolo, oltre a proporre una

de nizione, prova a delineare delle possibili applicazioni a ermando che l'Architettura Open Source prevede una totale revisione del processo architettonico: L'architettura open source rivoluziona tutte le fasi del processo edilizio tradizionale, dalla preparazione delle direttive di progetto alla demolizione e dalla programmazione al recupero e riuso, includendo i seguenti elementi: nanziamento, partecipazione, standard, progettazione, costruzione e uso. (Ratti et al. 2011a) Ă&#x2C6; da segnalare il fatto che l'editoriale di Domus, trasferito interamente su Wikipedia, ha contribuito a generare la prima pagina dell'enciclopedia libera sul tema dell'Architettura Open Source, disponibile in due lingue, inglese e italiano

In seguito, nel 2013, la rivista Boundaries pubblica un numero monotematico sul tema. Il titolo del volume Ă¨ Free Architecture, in onore, in questo caso, del Free Software di Stallman (Figura 4.3). Tuttavia, dal momento che all'interno del volume non viene fatta una chiara distinzione tra open source software e free software, sembra che la scelta del titolo sia stata motivata dalla volontĂ di distinguersi dal precedente numero di Domus (che intitolava l'editoriale all'Open Source Architecture ) piĂš che per motivi scienti ci. Per ciĂ˛ che concerne la tesi, nei capitoli precedenti Ă¨ giĂ stato spiegato come l'uso del termine Open Source sia piĂš adatto al tema: sia perchĂŠ fa riferimento diretto a un processo di sviluppo (il processo Open Source per l'appunto),

sia perchĂŠ l'ambivalenza del termine `free'

, pur contribuendo a fornire un

e cace background etico, non ne chiarisce i concetti pratici fondamentali ma crea confusione e ambiguitĂ . Ritornando a Boundaries, nell'articolo di Luca SampĂ˛, dal titolo Open-Source Culture, si traccia quella che potrebbe essere la piĂš recente istantanea del fenomeno: Architettura open source Ă¨ una de nizione relativamente recente, se paragonata alla storia del sotware libero e, malgrado si cerchi di attribuirle origini antiche, dal punto di vista dell'auto-coscienza Ă¨ appena nata. Salta agli occhi percorrendo il web come

9 http://opensource.org/osd

10 http://it.wikipedia.org/wiki/Architettura_Open_Source

11 In lingua inglese il termine `free' sta sia per libero che per gratuito.

CAPITOLO 4.

ARCHITETTURA OPEN SOURCE

Figura 4.3: La copertina del numero 7 del 2013 della rivista Boundaries (fonte:

//www.boundaries.it/).

http:

l'approccio di ognuno sia ancora ascrivibile a una fase iniziale, sperimentale e intuitiva, nella quale non Ă¨ possibile rintracciare una de nizione condivisa

4.1.

IL DIBATTITO CONTEMPORANEO

nĂ¨ circoscrivere il campo d'azione. I progetti sono molto di erenti tra loro, alcuni messi in rete come `open source' ma in realtĂ vincolati da forme di copyright, altri forniti con licenze Creative Commons (CC) che non sempre rispecchiano lo spirito originario dell'iniziativa in campo software. Orientarsi richiede tempo e anche un pizzico di conoscenze informatiche. Nel campo dell'open source i con ni tra architettura e le altre dsiscipline tendono a divenire meno de niti, a confondersi a bene cio di un atteggiamento collaborativo, inclusivo e interdisciplinare. (SampĂł 2013).

4.1.3 Una de nizione ancora aperta Ad oggi, nel complesso, una vera e propria de nizione di Architettura Open Source ancora non esiste, anche se molte iniziative si fregiano del titolo di `Open Source Architecture' (o appellativi a ni) sfruttando l'attuale mancanza di chiarezza sul tema. Tale fenomeno pone alcuni interrogativi dal punto di vista operativo, questioni che non possono essere risolte applicando una semplice etichetta (seppur particolarmente appetibile e `Ă la page') al progetto architettonico, ma richiedono un'analisi piĂš approfondita al ne di riuscire a replicare con successo un processo che nasce e si sviluppa nei limiti epistemologici di un'altra disciplina scienti ca. Dal momento che il modello di sviluppo Open Source comincia a penetrare in moltissimi settori dell'attivitĂ produttiva umana, Ă¨ e ettivamente lecito pensare che anche in architettura possa avvenire lo stesso, tenendo conto che anche in settori a ni all'architettura (come per esempio nel mondo del design) questo fenomeno Ă¨ giĂ in parte avvenuto ed Ă¨ in pieno sviluppo. Ma, oltre ai contributi teorici che si sono susseguiti nell'ultimo decennio, Ă¨ bene veri care se dal punto di visto pratico vi sono, o vi sono state, esperienze che hanno contribuito a sviluppare il discorso dell'Architettura Open Source non solo sulle riviste ma anche nella pratica quotidiana. L'applicazione di un modello Open Source all'architettura va dunque non solo illustrata attraverso la teoria, ma dimostrata e veri cata nella pratica, perchĂŠ proprio nell'applicazione pratica potrebbe in realtĂ dimostrarsi ine cace o addirittura impraticabile.

Risulta quindi

necessaria un'attenta analisi di ciĂ˛ che avviene a livello di esperienze concrete, indagando attentamente ciascun caso. Inoltre una attenta analisi dei fenomeni e delle esperienze in atto puĂ˛ portare a una piĂš e cace de nizione dei limiti applicativi e delle possibilitĂ di sviluppo futuro dell'Architettura Open Source.

Infatti solo attraverso l'analisi di casi pratici sarĂ possibile

dare una de nizione di Architettura Open Source, o quantomeno indicare cosa sicuramente non Ă¨ Architettura Open Source.

CAPITOLO 4.

4.2

ARCHITETTURA OPEN SOURCE

Lettura di un fenomeno emergente

4.2.1 Iniziative di Architettura Open Source Ai contributi teorici circa la de nizione di Architettura Open Source si a ancano esperienze pratiche e iniziative di notevole interesse le quali, non sempre in maniera appropriata, si auto-de niscono esperienze di Architettura Open Source. In questa seconda parte del capitolo verranno presi in esame sei casi esemplari. Ciascun caso Ă¨ stato inserito nell'elenco poichĂŠ a erma, dichiarandolo apertamente, di essere una iniziativa che mira a proporre un'applicazione del metodo di sviluppo Open Source nei processi di trasformazione dell'ambiente costruito. Oggetto dell'analisi che seguirĂ Ă¨ anche quello di appurare, per ogni singolo caso, se e come il tentativo di applicazione risulta riuscito o meno. Infatti in assenza di una vera e propria de nizione questa operazione Ă¨ necessaria. I casi studio esaminati sono riportati in ordine cronologico e descritti attraverso diverse chiavi di lettura. Oltre a una descrizione generale vengono presentati i promotori (che non sempre o non necessariamente sono architetti), viene spiegato il funzionamento dell'iniziativa e i concetti fondamentali che ne stanno alla base e viene presentato il processo di apertura, ovvero gli strumenti che, secondo i promotori stessi, dovrebbero garantire l'appellativo Open Source alla propria iniziativa. Oltre a questi dati, si analizzano i tre caratteri fondamentali delle iniziative Open Source, ovvero la sorgente, la comunitĂ e la piattaforma.

Verranno inoltre studiati due ulteriori aspetti:

il primo riguarda il business model, ovvero le strategie di nanziamento che ogni iniziativa adotta. Infatti a di erenza del software open source (che di solito prevede donazioni libere o al massimo campagne di crowdfunding, o ha direttamente dei canali propri di nanziamento attraverso venture capital), per l'architettura non esistono veri e propri canali di nanziamento, per cui i promotori scelgono alcune strade piuttosto che altre, e l'analisi di queste scelte o re importanti spunti per stabilire buone pratiche di sviluppo. Ă&#x2C6; necessario far notare che il nanziamento Ă¨ necessario poichĂŠ, a di erenza dello sviluppo software, in cui sono necessari solo qualche computer, una connessione a internet e l'a tto di uno spazio web, per quanto riguarda l'Architettura Open Source si tratta di iniziative che sviluppano prototipi, gestiscono infrastrutture e in alcuni casi utilizzano materiali costosi, di conseguenza vi Ă¨ una necessitĂ di nanziamento piuttosto alta (sebbene le cifre non sono esorbitanti: in genere si va da qualche migliaio di euro a poche decine di migliaia per le iniziative piĂš costose). Il secondo aspetto concerne i risultati ottenuti, ovvero l'attuale stato di avanzamento di ogni iniziativa e il suo impatto globale. Trovandosi di fronte a una sostanziale eterogeneitĂ sia di

4.2.

LETTURA DI UN FENOMENO EMERGENTE

pratiche che di dati disponibili, ogni iniziativa viene valutata rispetto alla sua attuale attivitĂ e alla sua comunitĂ . Al termine, ogni analisi Ă¨ corredata da alcune considerazioni riguardo l'e ettiva capacitĂ , da parte dei singoli casi, di mettere in atto un processo di Architettura Open Source. Tutti i dati che vengono presentati, dove non diversamente indicato, derivano dai siti web di ciascuna iniziativa e dai gruppi di discussione o forum della comunitĂ , i cui indirizzi sono indicati in nota all'inizio di ciascuna trattazione.

4.2.2 Un corpus di esperienze eterogeneo Come si vedrĂ poco piĂš avanti, in assenza di una speci ca de nizione, il corpus di esperienze signi cative risulta piuttosto eterogeneo e, a prima vista, con delle incoerenze.

CiĂ˛ avviene principalmente per alcuni motivi che si

analizzeranno di seguito. Il primo motivo Ă¨ di tipo cronologico: negli ultimi anni si Ă¨ assistito a uno sviluppo repentino e incessante di strumenti e fenomeni collaborativi attraverso lo sviluppo del web. Questo signi ca che una iniziativa del 2006 (sia essa legata all'architettura o meno) non potrĂ certamente disporre delle stesse tecnologie di una iniziativa piĂš recente: tra queste due esperienze si riscontreranno di erenze operative addirittura abissali. Dire che ogni giorno si inventa qualcosa non Ă¨ a atto azzardato e una di erenza di due anni tra due iniziative, che in linea teorica potrebbero anche essere considerate paragonabili, rischia di in ciarne la confrontabilitĂ nella pratica. In questa trattazione sono state incluse tutte le esperienze, anche se cronologicamente (e di conseguenza anche tecnologicamente) collocate in momenti di erenti.

Questo

perchĂŠ, nonostante la di erenza temporale possa compromettere l'operazione di confronto, vi sono comunque, come si vedrĂ in seguito, dei caratteri fondativi che trascendono la disponibilitĂ tecnologica dei casi osservati. Il secondo motivo Ă¨ dato dall'appetibilitĂ del termine Open Source. Proprio perchĂŠ legato a concetti di libertĂ , partecipazione, collaborazione e sostanziale democraticitĂ , il termine Open Source ha assunto dei signi cati che trascendono la sua natura pratica. Si Ă¨ dunque trasformato da metodo di sviluppo e cace e innovativo a contenitore di istanze supplementari che, seppur legittime e in alcuni casi anche corrette, rischiano di svuotare il signi cato del termine Open Source a favore di una generica etichetta di apertura. Tale etichetta risulta essere particolarmente allettante, sia perchĂŠ segna, senza soluzione di continuitĂ , un aggiornamento delle pratiche partecipative a una dimensione che potremmo de nire 2.0 (ovvero proiettata nella dimensione contemporanea in cui strumenti e applicativi web favoriscono l'interazione e la collaborazione), sia perchĂŠ si pone in posizione antitetica rispetto ai metodi di sviluppo e ai processi edilizi messi in atto dalla produzione architettonica

CAPITOLO 4.

ARCHITETTURA OPEN SOURCE

`mainstream', altrimenti detta delle `archistar'

. Questa dichiarazione anti-

tetica, in un momento in cui la crisi economica porta a mettere in discussione molti degli atteggiamenti progettuali in voga nel decennio passato de nendoli insostenibili, contribuisce a rendere il termine Open Source una `tag' da applicare a qualunque iniziativa non si allinei alla produzione architettonica odierna e che tenti di innescare processi inclusivi attraverso il web. Nell'insieme di esperienze che verrĂ illustrato, alcune fanno un uso strategico e non pratico del termine Open Source. Esse sono state incluse poichĂŠ, nonostante non si tratti di una vera e propria applicazione dell'Open Source all'architettura, la loro analisi risulta interessante per aspetti collaterali e contribuisce a ra orzare e a chiarire l'essenza dell'Architettura Open Source.

Un terzo motivo puĂ˛ essere individuato nella sostanziale diversitĂ dei temi a rontati:

se da un lato alcune esperienze prediligono temi speci ci e

circostanziati, altre si pongono come sistemi universali in grado di risolvere qualunque (o quasi) istanza architettonica, o ancora, qualunque istanza legata a uno speci co tema, in cui rientra anche l'architettura o la problematica abitativa. Come accennato nel paragrafo dedicato all'open design e all'open hardware, lo stesso accade in altri ambiti: cosĂŹ come vi sono iniziative ed esperienze che si focalizzano solo sul disegno di una sedia, altre che si concentrano sullo sviluppo di set di mobili e altre ancora che si propongono di sviluppare metodi di progettazione Open Source di qualsiasi oggetto, anche nel campo dell'Architettura Open Source vi sono approcci molto eterogenei. CosĂŹ come per la di erenza temporale di sviluppo, la diversitĂ di campo di applicazione e approccio non compromette l'operazione di confronto dal momento che vi sono comunque dei caratteri fondativi comuni a tutti i casi descritti.

A fronte di una varietĂ degli elementi presi in esame vi sono dei caratteri comuni che contribuiscono a chiarirne il funzionamento e a stabilire una completa comprensione del fenomeno nel suo complesso.

12 `Mainstream' e `archistar' sono de nizioni che non rendono giustizia a parte della produzione architettonica contemporanea, ma, essendo entrate a fare parte dell'attuale dibattito architettonico, vengono qui utilizzate per necessitĂ di sintesi e immediatezza di comprensione, non risultando comunque oggetto di trattazione o fondamentali per il prosieguo del discorso.

4.3.

CASI STUDIO

4.3

Casi studio

4.3.1 Open Architecture network

Open Architecture Network (OAN) Ă¨ una comunitĂ open source dedicata a migliorare le condizioni di vita a livello mondiale attraverso il design innovativo e sostenibile. Secondo quanto indicato nel sito: The Open Architecture Network is an online, open-source community dedicated to improving living conditions through innovative and sustainable design. Here designers of all persuasions can: 1) Share their ideas, designs and plans 2) View and review designs posted by others 3) Collaborate with each other people in other professions and community leaders to address speci c design challenges 4) Manage design projects from concept to implementation 5) Communicate easily amongst team members 6) Protect their intellectual property rights using the Creative Commons some rights reserved licensing system and be shielded from unwarranted liability 7) Build a more sustainable future

Lo scopo della piattaforma Ă¨ quello di permettere ad architetti, designer, innovatori e leader della comunitĂ di condividere idee, progetti e piani innovativi e sostenibili. OAN Ă¨ diventato un punto di riferimento e un vasto archivio di progetti (sono disponibili disegni de nitivi ed esecutivi, foto di cantiere, etc.) che presentano come tema l'architettura per lo sviluppo. Tutto il materiale pubblicato Ă¨ distribuito con licenza Creative Commons ed Ă¨ quindi riusabile e modi cabile. OAN Ă¨ un repository di progetti e una piattaforma di incontro tra diversi utenti, oltre a ciĂ˛ promuove e ospita concorsi di idee.

13 In questo paragrafo si fa esplicitamente riferimento, ove non diversamente indicato, al sito web dell'Open Architecture Network

http://openarchitecturenetwork.org/

alle informazioni contenute al suo interno.

Il sito Ă¨ stato consultato l'ultima volta nel

novembre del 2013.

14 L'Open Architecture Network Ă¨ una comunitĂ open source dedicata al miglioramento

delle condizioni di vita attraverso la progettazione innovativa e sostenibile. Qui qualunque progettista puĂ˛:

1) condividere idee, progetti e disegni 2) vedere e correggere progetti

pubblicati da altri 3) collaborare con altre persone e altri professionisti per a rontare speci che s de progettuali 4) gestire dei progetti dal concept no all'esecutivo 5) Comunicare facilmente con altri utenti 6) proteggere la sua proprietĂ intellettuale attraverso l'uso di opportune licenze di tipo Creative Commons 7) Costruire un futuro sostenibile. [traduzione italiana a cura dell'autore].

100

Promotori

CAPITOLO 4.

ARCHITETTURA OPEN SOURCE

OAN Ă¨ stata fondata nel 2006 da Cameron Sinclair e Kate

Stohr, soci fondatori di Architecture for Humanity (AfH), un'agenzia di progettazione no-pro t

fondata nel 1999. OAN Ă¨ uno strumento annunciato da

Sinclair nel 2006 in occasione del ricevimento del TED Prize. The TED Prize came at exactly the right moment for us. We were at this critical point where we had to scale up we needed a whole lot of technology and design help to do it. Our groups were using a combination of Meet-up, Facebook, Google Groups and four other web apps just to try and organize themselves at the heels of three major disasters. We're talking the tsunami, hurricane Katrina and the earthquake in Pakistan. There was no common place to share les. We couldn't do our work e ectively.

(Zjawinski 2007) A fronte del succes-

so di AfH, Sinclair e Stohr si trovano a gestire una organizzazione piuttosto ampia, con piĂš di 40 liali nel mondo e circa 200 progetti portati a termine nei 7 anni precedenti. L'architettura open-source Ă¨ la strada da seguire. C'Ă¨ una variegata comunitĂ di partecipanti, e non stiamo solamente parlando di inventori e progettisti, ma stiamo parlando del modello di nanziamento. Il mio ruolo non Ă¨ quello di progettista; Ă¨ di collegamento tra il mondo del progetto e il mondo umanitario. E ciĂ˛ di cui abbiamo bisogno Ă¨ di qualcosa che mi replichi questo processo a livello globale . (Sinclair 2006) Basandosi sulla positiva esperienza open source nel campo del software, sviluppano una piattaforma in grado di collegare progettisti, nanziatori e bene ciari con l'obiettivo di farla diventare un repository di soluzioni che possono essere utilizzate da ciascun utente secondo le sue necessitĂ : Quindi Ă¨ importante che queste idee veri cate niscano lĂ (nell'OAN, n.d.r), semplici da usare, facili da prendere. (Sinclair 2006)

Come funziona

OAN Ă¨ un repository di progetti, ovvero un archivio digi-

tale piuttosto grande di materiale pronto all'uso, organizzato secondo alcune categorie. Si parte dall'area geogra ca (continente e nazione), passando per le condizioni climatiche del sito, la funzione che dovrebbe ospitare il progetto e i principali temi a rontati. Oltre a queste macro categorie Ă¨ possibile inserire dei ltri di ricerca ulteriori. Ogni scheda progetto presenta le informazioni

15 http://architectureforhumanity.org/

16 Il premio TED Ă¨ arrivato esattamente al momento giusto per noi. Eravamo arrivati a quel punto critico in cui devi aumentare di scala, avevavmo bisogno di un enorme aiuto tecnologico e progettuale per farlo.

I nostri gruppi usavano una combinazione di stru-

menti quali Meet-up, Facebook, Google Groups e quattro altre applicazioni web solo per organizzarsi tra di loro durante tre grandi disastri naturali. Staimo parlando dell'uragano Katrina, dello tsunami e del terremoto in Pakistan. Non esisteva una piattaforma comune attraverso cui condividere i le. Non riuscivamo a fare il nosto lavoro in maniera e cace. [traduzione italiana a cura dell'autore].

4.3.

101

CASI STUDIO

base su quell'iniziativa (autori, bene ciari, donatori, luogo di realizzazione etc.)e una serie di documenti, che comprendono i disegni esecutivi no alle foto di cantiere (Figura 4.4).

L'idea di base Ă¨ che il progetto possa essere

seguito dalla comunitĂ in tutte le sue fasi, dall'ideazione alla manutenzione. Attraverso lo strumento dei commenti Ă¨ possibile interagire pubblicamente con i gestori del progetto, previa la registrazione al sito. Un form apposito permette anche di entrare in contatto con i gestori in maniera privata.

Figura 4.4: La pagina principale di un progetto ospitato dall'Open Architecture Network. Si tratta del Kabondo Football for Hope Centre a Bujumbura, in Burundi. Si puĂ˛ notare in basso a destra il simbolo della licenza Creative Common e, poco piĂš in alto, tutte le informazioni relative al progetto e i crediti (fonte:

org/projects/ffh_bujumbura).

Processo di Apertura

http://openarchitecturenetwork.

OAN puĂ˛ essere considerata una piattaforma `open'

in quanto tutto il materiale presente in essa Ă¨ distribuito attraverso le licenze Creative Commons. Inizialmente veniva usata la Developing Nations License, la quale permetteva un utilizzo libero dei contenuti unicamente nei paesi in via di sviluppo e con l'obbligo di attribuzione. Ora tale licenza non Ă¨ piĂš in uso e possono essere scelte a discrezione dell'utente tutte le varianti o erte da Creative Commons. L'accesso al sito Ă¨ libero previa registrazione, che Ă¨ gratuita.

102

CAPITOLO 4.

Sorgente

ARCHITETTURA OPEN SOURCE

La sorgente sono i progetti stessi e, nella fattispecie, tutto il ma-

teriale digitale caricato sulla piattaforma che ad essi si riferisce.

In alcuni

casi si tratta di disegni esecutivi anche piuttosto dettagliati, in altri di schemi di costruzioni elementari ma e caci, altre volte si tratta di diagrammi e immagini rappresentative. Essendo rilasciato con licenza Creative Commons, tutto il materiale può essere usato anche in altri contesti.

Ogni utente ha

la possibilità di organizzare il materiale reso disponibile come meglio crede. Attraverso la creazione di cartelle e di categorie di le (tra queste piante, sezioni, prospetti, dettagli, rendering, fotogra e, fotogra e dell'edi cio costruito) si può organizzare il proprio repository (Figura 4.5).

Non vi è un

formato di le richiesto, ognuno può decidere se condividere un le modi cabile (ad esempio un le autocad) o una semplice immagine del disegno, o tutte e due.

Ovviamente si tratta di una sorgente piuttosto eterogenea,

poiché non vi è uno standard sul tipo di elaborati da condividere, ma ogni utente è libero di scegliere come e quali elaborati condividere. Viene lasciata all'utente la scelta di condividere elaborati comprensibili anche ai non addetti ai lavori o meno, se condividere gli esecutivi e i dettagli di un progetto o meno.

Il grado di apertura non è imposto ma lasciato alla libera scelta

dell'utente.

Figura 4.5:

La pagina dei materiali scaricabili relativi al Kabondo Football for Hope

Centre a Bujumbura, in Burundi.

In questo caso speci co sono scaricabili liberamente

tutti i disegni di progetto, compresi gli esecutivi, i computi metrici, e tutte le foto di cantiere, oltre a una serie di altri materiali (fonte:

org/projects/ffh_bujumbura).

http://openarchitecturenetwork.

4.3.

103

CASI STUDIO

ComunitĂ

La comunitĂ Ă¨ variegata e nella mente dei promotori dovrebbe

comprendere un ampio spettro di utenti: Architects, designers, engineers and anyone else involved in the building trades is welcome to share their ideas on the Open Architecture Network - but the site is not just for professionals. Community leaders, nonpro t groups, volunteer organizations, government agencies, technology partners, healthcare workers, educators and others are also invited to collaborate on projects and share their expertise. After all if we're to meaningfully address the challenges of building a sustainable future, we'll need (a lot of ) help from people of all walks of life.

Sono dunque invitati a partecipare i possibili bene ciari dei progetti, i quali dovrebbero essere in grado di appropriarsi di progetti che sembrano incontrare le loro necessitĂ e modi carli a loro uso e consumo. Lo stesso discorso vale per i progettisti e gli addetti ai lavori, i quali possono utilizzare i progetti lĂŹ conservati per i propri scopi o contribuire con idee proprie. Un elemento importante Ă¨ anche quello dei nanziatori, i quali hanno la possibilitĂ di scegliere a quali progetti partecipare attraverso un nanziamento.

Piattaforma

OAN si delinea come un eneorme repository di progetti, of-

frendo la possibilitĂ a ciascun utente di aprire una pagina dedicata alla propria iniziativa, con la possibilitĂ di coinvolgere anche altri utenti. La pagina del progetto dĂ la possibilitĂ di inserire informazioni dettagliate circa il proprio lavoro e, soprattutto, di creare una timeline (dalla fase di progettazione no alla realizzazione) dando la possibilitĂ di caricare e rendere disponibile tutto ciĂ˛ che si vuole (ciĂ˛ comprende le cad di ogni fase del progetto, immagini, computi metrici, diagrammi di Gantt, informazioni riguardanti la gestione del cantiere etc.). Ă&#x2C6; ovviamente possibile commentare e confrontarsi con gli altri su ogni progetto inserito. Tutti i progetti di AfH sono inseriti e le loro pagine vengono regolarmente aggiornate dai responsabili di progetto o da altri utenti coinvolti.

Business model

The Open Architecture Network was the result of a year-

long partnership that began in spring 2006 when Architecture for Humanity won the prestigious TED Prize. [...] We envisioned a truly collaborative online community and gathering place for those dedicated to improving the built

17 Architetti, designer, ingegneri e chiunque sia coinvolto nell'industria edilizia Ă¨ benvenuto e puĂ˛ condividere le sue idee sull'Open Architecture Network - ma il sito non Ă¨ solo per professionisti. Leader di comunitĂ locali, partner industriali, addetti alla sanitĂ , organizzazzioni di volontari, educatori e altri sono invitati a collaborare ai progetti e a condividere la loro esperienza. Dopotutto a rontiamo la s da di costruire un futuro sostenibile, abbiamo bisogno di parecchio aiuto da persone di ogni genere e tipo. [traduzione italiana a cura dell'autore].

104

CAPITOLO 4.

ARCHITETTURA OPEN SOURCE

environment. Sun Microsystems, Hot Studio, Creative Commons, AMD and other partners joined Architecture for Humanity in realizing this ambitious undertaking, and at this year's TED conference, together we launched a beta version of the Open Architecture Network: the rst site to o er open source architectural plans and blueprints on the web.

Il sito si pone oltre che

come piattaforma di collaborazione anche come vetrina per l'attivitĂ di architecture for humanity, dal momento che tutti i progetti dell'associazione sono ospitati su questa piattaforma e accessibili dal sito di AfH tramite link. Il sito viene mantenuto dal AfH: sono presenti banner contenenti richieste di donazioni a favore AfH sul sito di OAN. Ciascun progetto presente, se non promosso da AfH, ha i suoi propri canali di nanziamento indipendenti, dal momento che la piattaforma non o re nessun tipo di incentivo economico o donazione.

Risultati

Il sito attualmente ha piĂš di 400.000 utenti registrati e ha pro-

mosso 21 concorsi. Al momento ospita piĂš di 10.000 progetti cosĂŹ suddivisi per aree geogra che: Nord America (37,6%) Africa e Paesi Arabi (20,34%) Asia e Paci co (19,23%) America Latina e Caraibi (15,10%) Europa ed ex-Stati Sovietici (7,73%) Oltre a ciĂ˛ Open Architecture Network ha dato il via a molte altre esperienze dello stesso tipo, dal funzionamento simile o comunque assimilabile,

tra cui Architecture in Devlopment

o Urbaninform

Open Architectu-

re Network ha dunque stabilito una maniera di condivisione del progetto di architettura che ha fatto scuola.

Considerazioni generali

Si tratta, attualmente, della piĂš grande comuni-

tĂ online che si occupa di Architettura Open Source. La forma di repository non Ă¨ cambiata dalla sua fondazione e la piattaforma non si Ă¨ mai evoluta, presentando una interfaccia semplice e con ridotte possibilitĂ di interazione.

18 L'OAN Ă¨ il risultato di una partnership che Ă¨ iniziata nel 2006 quando AfH ha vinto il prestigioso premio TED. [...] Abbiamo immaginato una comunitĂ di collaborazione online e costruito un punto di incontro per coloro che intendono cambiare in meglio l'ambiente costruito. Sun Microsystems, Hot Studio, Creative Commons, AMD e altri partner si sono uniti ad AfH per realizzare questo obiettivo ambizioso, e in quell'anno, alla conferenza TED, abbiamo lanciato insieme la prima versione dell'OAN: il primo sito in grado di o rire progetti architettonici open source. [traduzione italiana a cura dell'autore].

19 http://www.architectureindevelopment.org/ 20 http://www.urbaninform.net/

4.3.

105

CASI STUDIO

Ha il grande pregio di lasciare agli utenti la possibilità di de nire la natura della sorgente, tuttavia questo pregio diventa anche il maggiore difetto: infatti una pubblicazione non accurata dei documenti di progetto può limitare notevolmente la loro distribuzione e utilità. I sorgenti della piattaforma non sono liberamente distribuiti. La sua grandezza permette a chiunque voglia, previa registrazione, di utilizzare tutte le potenzialità della piattaforma in forma gratuita: ciò potrebbe facilitare, in teoria, la nascita di nuove iniziative Open Source che potrebbero utilizzare parzialmente le risorse di OAN per lanciare la loro iniziativa senza particolari costi di gestione. OAN ricorda per certi versi il ` atwriter' di Friedman.

Attraverso la

navigazione sul sito e l'utilizzo di appropriati ltri di ricerca, l'utente (che può essere il leader di una comunità locale, il rappresentante di una organizzazione di volontariato, uno studente di architettura o ingegneria etc.)

può avere

accesso a un database ragionato di soluzioni pronte all'uso. La piattaforma si pone quindi come `traduttore' in grado di accompagnare l'utente nella ricerca di risposte progettuali che soddisfano le sue necessità.

4.3.2 Open Structures

Open Structures è una piattaforma collaborativa basata sull'utilizzo di una griglia da disegno comune, la quale permette la progettazione, lo sviluppo e la produzione di oggetti intercambiabili e compatibili tra di loro, che possono arrivare a comporre sia piccoli oggetti che grandi strutture. The OS (OpenStructures) project explores the possibility of a modular construction model where everyone designs for everyone on the basis of one shared geometrical grid.

It initiates a kind of collaborative Meccano to which everybody can

contribute parts, components and structures.

Promotori

(Figura 4.6).

Il progetto Openstructures è un processo collaborativo. Con-

cepito originariamente da Tomas Lommée presso l'Insitute without boundaries nel 2007, si è evoluto grazie al lavoro di Infrasctructures, lo studio di Lommée, in collaborazione con diversi partner.

La fase sperimentale di

questa ricerca ha ricevuto sostegno strutturale e produttivo da 233, House

21 In questo paragrafo si fa esplicitamente riferimento, ove non diversamente indicato, al sito web di Open Structures

http://openstructures.net/ e alle informazioni contenute

al suo interno. Il sito è stato consultato l'ultima volta nel novembre del 2013.

22 Il progetto OpenStructures esplora le possibilità della costruzione modulare all'interno

della quale chiunque progetta per chiunque sulla base di una griglia geometrica condivisa. Innesca una specie di Meccano collaborativo a cui chiunque può contribuire attraverso parti, componenti e strutture. [traduzione italiana a cura dell'autore].

106

CAPITOLO 4.

ARCHITETTURA OPEN SOURCE

Figura 4.6: La homepage del sito OpenStructures. È possibile vedere, nella parte bassa, uno dei pezzi progettati e prodotti da uno degli utenti. (fonte:

net/).

http://openstructures.

for contemporary Arts in Hasselt, Belgio. (Lommée 2011).

Il progetto è

nato come progetto di ricerca con diversi nanziamenti per poi proseguire in maniera indipendente.

Come funziona

Il cuore del progetto è composto da una griglia di 4 x 4

cm. L'utente, disegnando oggetti sulla griglia, seguendo le linee di costruzione già predisposte e alcune semplici regole, si assicura automaticamente che ogni oggetto da lui disegnato sia compatibile con tutti gli altri oggetti disegnati nella stessa modalità. La griglia è anche disponibile in versioni più grandi nel caso si vogliano disegnare oggetti più grandi.

Orientata perlopiù alla

de nizione di oggetti in legno e metallo, lo stesso metodo può essere utilizzato con le moderne stampanti 3d, ampliando di molto le possibilità produttive. La produzione dei pezzi è pensata per essere fatta direttamente da ciascun utente con gli strumenti che ha a propria disposizione.

L'intento è quello

di creare una sorta di `esperanto universale' per oggetti in modo tale che possano essere sempre compatibili tra loro e ricombinabili secondo le proprie esigenze (Figura 4.7).

4.3.

107

CASI STUDIO

Figura 4.7: Lo schema concettuale che rappresenta il funzionamento di OpenStructures. Dalla griglia di partenza si passa alle singole parti, poi ai componenti, poi alle strutture e in ne alle superstrutture, analogamente a quanto avviene per l'organismo. (fonte:

//openstructures.net/).

Processo di Apertura

http:

Il sito web Ă¨ accessibile a tutti previa registrazione

(e-mail necessaria), cosĂŹ come la griglia (sia nella versione stampabile che nella versione digitale).

La griglia non ha nessun tipo di licenza: Ă¨ liberamente

scaricabile e utilizzabile.

Invece gli oggetti creati sono sottoposti a licenze

Creative Commons a discrezione dell'autore dell'oggetto stesso.

Sorgente

La sorgente Ă¨ plurima: da un lato la griglia e le regole di utiliz-

zo, che ne costituiscono il corpus principale e che possono essere considerate la sorgente primaria; dall'altro lato gli oggetti stessi i quali, se ricombinati e cacemente, possono portare alla costruzione di nuovi oggetti o nuove strutture. Ă&#x2C6; dunque un sistema di sorgente progettuale a cascata: data una sorgente iniziale, si permette lo sviluppo di prodotti che possono essere considerati sia prodotti niti rispondenti una speci ca problematica, sia essere reinseriti nel circuito producendo nuovi oggetti compositi.

L'utente che si

a accia per la prima volta a OpenStructures ha la possibilitĂ di accedere a un database di soluzioni giĂ pronte all'uso o di sviluppare da zero la propria

108

CAPITOLO 4.

ARCHITETTURA OPEN SOURCE

idea.

Comunità

La comunità è composta da designer e progettisti che utilizza-

no la griglia, ma anche da semplici appassionati. Ogni utente partecipa alla piattaforma postando direttamente i frutti del proprio lavoro. È anche prevista la possibilità di acquistare il prodotto nito da altri utenti (il disegno è sempre disponibile gratuitamente sotto licenza creative commons). I pezzi che prevedono lavorazioni particolari o complesse possono essere comperati dall'utente che li produce, al prezzo da lui ssato.

Piattaforma

La piattaforma consente di caricare e rendere pubblico ogni

singolo oggetto disegnato attraverso il caricamento sul sito di una foto, del le in formato dxf associato (tipologia di le che può essere letta da programmi cad free o gratuiti, o direttamente da macchine a controllo numerico) e delle indicazioni, nel caso si tratti di un oggetto facente parte di una struttura più complessa. Oltre alle informazioni generali e alle istruzioni per l'uso vi sono anche tutti i lavori eseguiti dagli utenti.

Business model

Proprio per il fatto di permettere la vendita degli oggetti

la piattaforma favorisce la creazione di una microeconomia interna fatta di scambi di pezzi già prodotti. Ha ricevuto un sostegno strutturale e produttivo da 233, House for contemporary Arts in Hasselt, in Belgio.

Risultati

Ad oggi la piattaforma consta di 134 oggetti disponibili, i quali

vanno dalla singola piastrina di collegamento a oggetti interi (biciclette o nodi strutturali). Contiene un numero molto superiore di componenti base rispetto ai 134 oggetti disponibili in partenza. Per quanto riguarda l'architettura Open Structures è stato adottato, oltre che per strutture sperimentali, dallo studio belga Brussels Cooperation per sviluppare il progetto di un mercato coperto a Katanga, in Congo (Figura 4.8). Il progetto tuttavia non è stato realizzato. Il metodo progettuale è stato utilizzato per il disegno di tutti i nodi strutturali, andando a studiare un congegno che permettesse l'e cace accoppiamento tra elementi a sezione tonda ed elementi a sezione quadrata. Sono ancora in fase di sviluppo strutture più complesse.

Considerazioni generali

Open Structures basa tutto il suo funzionamen-

to sugli standard e la interoperabilità tra i pezzi prodotti, la cui ricombinazione dovrebbe essere in grado di generare in nite soluzioni. Dal momento che non sono state sviluppate particolari interfacce o strumenti di progettazione assistita, la piattaforma continua a essere utilizzata perlopiù da addetti ai

4.3.

109

CASI STUDIO

Figura 4.8: Il progetto di giunto tra elementi a sezione quadrata ed elementi a sezione tonda, sviluppato da Brussels Cooperation per il progetto di un mercato coperto a Katanga, in Congo. (fonte:

http://openstructures.net/).

lavori, che decidono di sviluppare i propri progetti con questo metodo. Per quanto riguarda l'architettura il contributo è al momento piuttosto limitato, ma sembra aver trovato una dimensione stabile nella progettazione di nodi strutturali leggeri e essibili.

La mancanza di una fonte di nanziamento,

sia essa basata su donazioni o su altre fonti, non ha probabilmente permesso la costruzione di prototipi di grande scala e lo sviluppo adeguato della piattaforma.

4.3.3 OpenSimSim

Open SimSim (Open Source Architecture) è una piattaforma collaborativa nata nel 2009 su inziativa di Daniel Dendra. È stata presentata alla biennale di Venezia nell'anno successivo. Pensata come piattaforma di collaborazione focalizzata sull'architettura, è stata promotrice nel 2011 dell'iniziativa OpenJapan. Open source architecture is a community driven platform that

23 In questo paragrafo si fa esplicitamente riferimento, ove non diversamente indicato, al sito web dei Open Sim Sim

http://opensimsim.net/

e alle informazioni contenute al

suo interno. Il sito è stato consultato l'ultima volta nel novembre del 2013.

110

CAPITOLO 4.

ARCHITETTURA OPEN SOURCE

enhances the architectural design and building process. Open source architecture deals with wide range, innovative and sustainable housing concepts. It provides user generated content including scripting tools and with it valuable knowledge.

The design process and realization of architecture are

de ned in a contemporary way: An interested community such as architects, engineers, climate specialists, home owners, designers and manufactures are putting their input and feedback into the design. It is available to everybody who cares about the world of design and the design of the world. The goal is to de ne new objectives, develop strategies to initiate activities, meet people in architecture, make the design process more transparent and create new visions. Architectural design for homes should be for free, as long it is sustainable.

Promotori

Promotore principale dell'iniziativa è l'architetto berlinese Da-

niel Dendra e il suo studio, anOtherArchitect. Lo studio propone, sulla falsariga dell'esperienza Open Sim Sim, anche altre iniziative come il Cloudscapes Award

e Future city labs

Come funziona

Open Sim Sim si con gura come una piattaforma di scam-

bio di informazioni ed esperienze che propone iniziative di progettazione collaborativa aperta. La più rilevante di queste è stata OpenJapan, organizzata in seguito al maremoto e terremoto in Giappone dell'11 marzo 2011. Attraverso degli eventi di questo tipo, limitati nel tempo, la piattaforma Open SimSim intende portare avanti la sua attività collaborativa. Nel particolare, OpenJapan è stato un evento temporaneo della durata di tre giorni. Dopo una call generale, sono state individuati 8 gruppi in 8 città del mondo che, in base al fuso orario, hanno lavorato per 8 ore al giorno sui temi proposti dal

24 Open Source Architecture è una comunità guidata da una piattaforma che tenta di migliorare il disegno architettonico e il processo di costruzione.

L'architettura Open

Source ha a che fare con un'ampia gamma di concetti abitativi innovativi e sostenibili. Permette all'utente di generare contenuti di vario genere tra cui gli strumenti di scripting e le preziose conoscenze che ne derivano. Il processo di progettazione e la realizzazione di strutture architettoniche sono de niti in contemporanea: la comunità coinvolta, che può essere composta da archittetti, ingegneri, specilaisti del clima, proprietari di case, progettisti e costruttori, mettono il loro input e fedback all'interno del progetto. Quest'ultimo rimane disponibile per tutti coloro che sono interessati al mondo della progettazione e alla progettazione del mondo. Lo scopo è quello di de nire nuovi obiettivi, sviluppare strategie che promuovano attività concrete, incontrare persone in ambito architettonico, rendere il processo di progettazione più trasparente e creare nuove idee.

Il disegno architettonico

dovrebbe essere gratis a patto che sia sostenibile. [traduzione italiana a cura dell'autore].

25 http://www.cloudscap.es/award 26 http://ftrctlb.com/

4.3.

111

CASI STUDIO

gruppo giapponese. Scambiandosi il lavoro e le informazioni prodotte tra un turno e l'altro, è stato posto in essere un processo di `collaborative design' i cui risultati sono stati interamente pubblicati sulla piattaforma pensata per l'occasione, che al momento non è però più reperibile online (Figura 4.9)

Figura 4.9: Schema di funzionamento dell'iniziativa OpenJapan. Il usso di lavoro viene gestito in cicli di 8 ore ciascuno dalle varie sedi operative sparse nel mondo (fonte:

//openjapan.opensimsim.net/,

Sorgente

http:

il sito non è più raggiungibile al momento).

Prendendo in esame una iniziativa come OpenJapan, la sorgente

sono delle idee progettuali o metaprogettuali che vogliono essere delle risposte a degli input dati all'inizio del processo.

La sorgente era quindi data

dall'insieme di tutti questi materiali, organizzati e presentati a discrezione dell'utente, nel formato ritenuto più consono (Figura 4.10).

Comunità

Data la componente espressamente progettuale e sperimentale,

la comunità è composta perlopiù da architetti, urbanisti o designer.

Piattaforma

La piattaforma di Open SimSim consiste in un sito web e di-

versi altri canali di comunicazione (social network). Ogni iniziativa proposta ha una piattaforma a sé stante, la quale contiene proposte progettuali che

27 Alla re

della

va,

iniziativa tesi.

sede

essendo

di il

OpenJapan Il

centro

Cluster sito

partecipato

torinese

Magazine.

principale

non

prima

OpenJapan oggi

non

raggiungibile.

persona stato

sono

Sul

più

sito

anche

l'auto-

organizzato tracce

pres-

dell'inziat-

Cluster

Magazi-

http://www.cluster.eu/2011/06/08/ torino-con-10-città-del-mondo-per-un-progetto-in-72-ore-openjapan/.

ne è presente un articolo illustra l'iniziativa:

112

CAPITOLO 4.

ARCHITETTURA OPEN SOURCE

Figura 4.10: Uno dei documenti prodotti durante OpenJapan. La libera scelta dell'utente, riguardo alla modalità di confezionare la sorgente, ha prodotto elaborati di diverso tipo. In questa immagine vi è un disegno schematico fatto dall'architetto Corrado Curti presso la sede torinese dell'iniziativa.

L'immagine proviene dall'archivio personale dell'autore

della tesi ed era contenuta, quando raggiungibile, nel sito web di OpenJapan:

//openjapan.opensimsim.net/.

http:

possono essere modi cate seguendo il metodo wiki. Open Japan si presentava come un repository di idee metaprogettuali il cui sviluppo era documentato, dal momento che era possibile tenere traccia di tutte le modi che apportate no a quel momento.

Risultati

La piattaforma non sembra al momento attiva.

La scomparsa

del sito Open Japan contenente tutti i risultati dell'iniziativa è un chiaro sintomo dell'inattività complessiva del progetto.

Considerazioni generali

Sebbene sia stato presentata alla Biennale di

Venezia del 2010, la piattaforma presenta dei limiti strutturali notevoli. Innanzitutto non è stata scelta una sorgente adeguata.

Le idee progettuali,

sebbene presentate con immagini piuttosto attraenti e talvolta anche interessanti, scontavano la loro dimensione embrionale, vedendo poche possibilità di applicazione pratica reale. L'assenza di standard a tutti i livelli (standard formali, produttivi, ma anche di software e le usati) non permette una reale

4.3.

113

CASI STUDIO

interazione tra tutti i contributi, e la non presenza di le sorgente (ma solo di immagini, ad esempio) limita di molto il grado di apertura di ciĂ˛ che Ă¨ stato prodotto. Tale limitazione comporta anche la presenza di soli addetti ai lavori all'interno della comunitĂ . Dal punto di vista della piattaforma Ă¨ necessario notare che l'evento limitato nel tempo sebbene riesca a catalizzare una certa attenzione ed ad ottenere anche una buona partecipazione, presenti serie di coltĂ a continuare la sua attivitĂ al di fuori della sua dimensione di workshop.

4.3.4 Air Tree Commons

Presentato all'expo di Shanghai del 2010 presso il padiglione della cittĂ di Madrid, Air Tree Commons Ă¨ un progetto sviluppato dallo studio spagnolo Ecosistema Urbano (Figura 4.11). Riprende l'esperienza dell'Ecoboulevard

Figura 4.11:

Le immagini mostrano le varie con gurazioni dell'Air Tree Commons

presentato all'expo di Shanghai (fonte:

air-tree/).

http://ecosistemaurbano.com/portfolio/

a Vallecas, Madrid. Questa la descrizione che viene fatta sul sito dello studio: The Air Tree emerges as an experimental prototype of intervention in contemporary urban public space, capable of reactivating sites and creating the conditions to empower the use of the collective space.

It is conceived

as a technological urban furniture, which also serves as a virtual node of connectivity Madrid-Shanghai, where users can actively interact. Its di erent technical layers enables multiple nal con gurations and a myriad of intermediate positions (opaque, translucent, transparent, bright, interactive, open, etc.).

28 In questo paragrafo si fa esplicitamente riferimento, ove non diversamente indicato, al sito web dei Ecosistema Urbano

http://ecosistemaurbano.com/

e alle informazioni

contenute al suo interno. Il sito Ă¨ stato consultato l'ultima volta nel novembre del 2013.

29 Air Tree nasce come prototipo sperimentale di intervento nello spazio pubblico ur-

bano, capace di far rinascere luoghi sici e creare condizioni per migliorare l'utilizzo dello

114

CAPITOLO 4.

Promotori

ARCHITETTURA OPEN SOURCE

Il padiglione è stato sviluppato e realizzato dallo studio spagno-

lo Ecosistema Urbano, uno studio formatosi nel 2000 a Madrid. Ecosistema Urbano is a Madrid based group of architects and urban designers operating within the elds of urbanism, architecture, engineering and sociology. We de ne our approach as urban social design by which we understand the design of environments, spaces and dynamics in order to improve self-organization of citizens, social interaction within communities and their relationship with the environment.

Il committente dell'opera è la Fundación Madrid Ciudad Global 2010, costituita dal comune di Madrid appositamente per gestire la partecipazione all'expo di Shanghai nel 2010.

Come funziona

Air Tree Commons è una struttura progettata per gli

spazi pubblici pensata per implementare l'uso dello spazio pubblico da un punto di vista comunitario e collettivo. Il funzionamento dell'Air Tree Commons è legato al controllo degli agenti atmosferici e al garantire il comfort ambientale, anche in spazi esterni.

Il processo di apertura

Il progetto è disponibile sotto licenza Creative

Commons. In particolare sono stati distribuiti sotto questa particolare licenza tutti i disegni esecutivi dell'opera. Alla ne dell'Expo, nel novembre 2010, viene data comunicazione sul blog dello studio la decisione di rendere disponibile il progetto: El Árbol de Aire pasará a llamarse `Air Tree Commons', puesto que a partir de hoy el proyecto entrará a formar parte del Procomún: cualquier persona, entidad o empresa podrá copiarlo, construirlo, venderlo y modi carlo en total libertad.

Air Tree Commons será el primero proyecto

desarrollado para una Expo Universal que tras su clausura desarrolla su ciclo de vida como legado para toda la sociedad.

Lo studio si è sempre occupa-

spazio colletivo. È stato concepito come un arredo tecnologico urbano, che serve anche come nodo virtuale di connetività tra Madrid e Shanghai con cui gli utenti possono interagire attivamente. Le sue diverse componenti tecniche permettono multiple con gurazioni nali e una miriade di posizioni intermedie (opache, semi-trasparente, trasparente, luminoso, interattivo, aperto, etc.). [traduzione italiana a cura dell'autore].

30 Ecosistema urbano è un gruppo di architetti e di progettisti urbani di Madrid, i quali

operano in ambito urbanistico, architettonico, ingegneristico e sociologico. De niamo il nostro approccio come progettazione urbana siociale con cui comprendiamo la progettazione degli ambienti, degli spazi e delle dinamiche al ne di milgiorare l'auto-organizzazione dei cittadini, l'interazione sociale all'interno delle comunità e la loro relazione con l'ambiente circostante. [traduzione italiana a cura dell'autore].

31 `Árbol de Aire' cambierà nome in `Air Tree Commons', poiché da oggi il progetto

entrerà a far parte del Procomun: qualsiasi persona, entità o impresa potrà copiarlo, costruirlo, venderlo e modi carlo in piena libertà. Air Tree Commons sarà il primo progetto

4.3.

115

CASI STUDIO

to di temi legati al mondo dell'open source e delle reti collaborative. Infatti sul loro sito è presente una sezione chiamata Open Source all'interno della quale vi si possono trovare tutti le informazioni relative all'Air Tree Common e altri progetti (What if ?) di piattaforme collaborative. L'attenzione verso tali tematiche viene così riassunta: We like to keep things open -as in open source-, and free -as in free software-.

This means transparent, accessible,

inclusive, collaborative, modi able, reproducible.

This means more people

can be part of it and bene t from it. These are the attributes that de ne a project made for the common good, and we challenge ourselves to apply them whenever we can.

Strumenti

Il progetto è disponibile sotto licenza Creative Commons del

tipo Attribution:

Tu sei libero:

di riprodurre, distribuire, comunicare al

pubblico, esporre in pubblico, rappresentare, eseguire e recitare quest'opera; di modi care quest'opera; di usare quest'opera per ni commerciali.

Alle

seguenti condizioni: Attribuzione Devi attribuire la paternità dell'opera nei modi indicati dall'autore o da chi ti ha dato l'opera in licenza e in modo tale da non suggerire che essi avallino te o il modo in cui tu usi l'opera. Oltre a questo il progetto esecutivo è disponibile in formato pdf, formato non editabile.

Sorgente

La sorgente in questo caso è il disegno tecnico puro. Ciò compor-

ta un accesso da parte di utenti perlopiù addetti ai lavori. Inoltre il disegno tecnico è frutto di un processo progettuale basato sulla parametrizzazione di tutto il progetto attraverso l'utilizzo di software ad hoc.

Il progetto para-

metrico (che è la sorgente del progetto esecutivo) non è stato rilasciato né distribuito in alcuna forma (Figura 4.12).

Comunità

Nel caso dell'Air Tree Commons non è possibile individuare

una speci ca comunità che lavora sul progetto, infatti esso è stato sviluppato all'interno di uno studio professionale e reso libero in seguito. Chiunque può impossessarsi del progetto ma l'assenza di una piattaforma non permette lo realizzato per una Esposizione Universale, che dopo la sua chiusura sviluppa il suo ciclo di vita come lascito per tutta la società. [traduzione italiana a cura dell'autore].

32 Ci piace tenere le cose aperte - come nell'open source e libere come nel free

software. Ciò signi ca tenere le cose trasparenti, accessibili, inclusive, collaborative, modi cabili, riproducibili. Ciò signi ca che più persone possono farne parte e trarne bene ci. Queste sono le caratteristiche che de niscono un progetto realizzato per il bene comune, e noi ci impegniamo ad applicarle tutte le volte che ci sarà possibile. [traduzione italiana a cura dell'autore].

116

CAPITOLO 4.

ARCHITETTURA OPEN SOURCE

Figura 4.12: La natura parametrica dell'Air Tree Commons: attraverso la modi ca dei parametri che governano il modello parametrico Ă¨ possibile modi care la forma nale

http://www.immaginoteca.com/ ecosistema-urbano-air-tree-vers-une-architecture-creative-commons).

dell'edi cio adattandolo alle proprie necessitĂ (fonte:

svilupparsi di una comunitĂ attiva. Non si puĂ˛ quindi parlare di Architettura Open Source

Piattaforma

Ă&#x2C6; sostanzialmente assente una piattaforma vera e propria.

Il sito web dello studio e il blog si limitano a distribuire i disegni esecutivi dell'opera, ma nella realtĂ non contribuiscono al formarsi di una comunitĂ (non vi sono forum nĂŠ gruppi di discussione) e soprattutto non permettono di alloggiare le eventuali versioni modi cate o migliorate.

Business model

Il modello di business si basa non sulla vendita del pro-

getto in sĂŠ, ma sulla vendita di un servizio legato all'Air Tree Commons. Se il progetto Ă¨ gratuito, non Ă¨ gratuita la direzione della produzione dei lavori o l'eventuale modi ca del progetto stesso nel caso esso debba essere adattato a di erente condizioni ambientali (Figura 4.13).

Risultati

Non vi sono al momento risultati conosciuti, ovvero non vi Ă¨

notizia di eventuali copie o progetti di sviluppo paralleli a quello originale.

Considerazioni generali

Il progetto aveva come obiettivo quello di foca-

lizzarsi sullo spazio pubblico, tuttavia presenta dei forti limiti.

Viene pre-

sentato come progetto Open Source, ma questa dicitura, sebbene piuttosto a ascinante, risulta essere fuorviante. Infatti la sorgente Ă¨ stata interamente sviluppata da uno studio professionale e mai resa disponibile a terzi: la presenza in rete dei disegni esecutivi non Ă¨ infatti su ciente a garantire la necessaria apertura al progetto. Inoltre bisogna considerare che la vera sorgente

4.3.

117

CASI STUDIO

Figura 4.13:

I due schemi illustrano il processo che il rilascio sotto licenza Creative

http://complexitys.com/francais/ shanghai-air-tree-le-premier-projet-darchitecture-creative-commons/). Commons del progetto dovrebbe innescare (fonte:

che registra e governa il progetto Ă¨ di tipo parametrico, ovvero modi cabile e adattabile anche solo agendo su parametri di base, ma non Ă¨ stata resa disponibile. L'assenza di una piattaforma adeguata contribuisce a quali care questa iniziativa come Open Source unicamente sulla carta (e sul website dello studio Ecosistema Urbano

Non Ă¨ dato sapere che tipo di processo avrebbe innescato il rilascio della sorgente vera e propria del progetto, tuttavia sarebbe stato certamente interessante vedere quale implementazione avrebbe potuto avere un modello parametrico, anche piuttosto complicato, se lasciata nelle mani di una comunitĂ interessata al suo sviluppo.

4.3.5 Open Source Ecology

Open Source Ecology Ă¨ una inizaitiva Open Source focalizzata sullo sviluppo a basso costo dell'ambiente rurale: OSE (Open Source Ecology) Ă¨ un network di scienziati dell'agricoltura con base nel Kansas: agronomi, ingegneri e semplici sostenitori che aspirano a un modello alternativo e autosu ciente di civilizzazione.

Da questa comunitĂ , Guidata da Marcin Jakubowski, Ă¨

nato il Global Village Construction Set, un kit per l'autocostruzione di 50 di erenti macchine agricole. Un Lego a misura d'uomo che fa dell'open source, della modularitĂ , del basso costo e della pratica fai-da-te un quadro di riferimento collaborativo capace di invertire la tendenza all'impoverimento delle comunitĂ rurali. (Manaugh 2011).

33 http://ecosistemaurbano.com/portfolio/tag/open-source/

34 In questo paragrafo si fa esplicitamente riferimento, ove non diversamente indicato, al sito web dei Open Source Ecology

http://opensourceecology.org/

e alle informazioni

contenute al suo interno. Il sito Ă¨ stato consultato l'ultima volta nel novembre del 2013.

118

CAPITOLO 4.

Promotori

ARCHITETTURA OPEN SOURCE

OSE Ă¨ stata fondata nel 2003 da Marcin Jakubowski, un gio-

vane ricercatore in sica nucleare all'UniversitĂ del Wisconsin, che dal 2008 si Ă¨ stabilito presso una fattoria vicina a Kansas City (Missouri), ribattezzata `Factor E Farm'. A partire dal 2011 la presenza di Jakubowski presso i TED Talk, Maker Faire e altri rilevanti appuntamenti ha permesso di far conoscere a un pubblico sempre piĂš ampio l'iniziativa.

Questa popolaritĂ

ha permesso di chiudere con successo una campagna di crowdfunding

nel

2011 (attraverso la piattaforma di crowdfunding Kickstarter sono stati raccolti 63,573 dollari americani) ed Ă¨ attualmente sostenuta economicamente dalla Shuttleworth Foundation.

Come funziona

OSE Ă¨ un struttura piuttosto complessa, formata da di-

verse parti dialoganti tra di loro. Principalmente si basa sull'idea che l'impoverimento rurale (in questo caso degli Stati Uniti, ma si potrebbe applicare a molte altre parti del mondo) possa essere a rontato e cacemente e a basso costo attraverso l'utilizzo di macchinari sviluppati secondo il metodo Open Source. Proponendo quindi il Global Village Construction Set (un set di 50 macchine autocostruibili e replicabili) mira a fornire un set base di strumenti che possono essere utilizzati per l'economia rurale. Tra queste macchine, alcune possono essere usate anche per costruire abitazioni o altri edi ci rurali.

Processo di Apertura

Lo sviluppo delle macchine e tutta la documen-

tazione per la loro realizzazione Ă¨ Open Source, come anche tutta la documentazione legata ai prodotti terzi che possono esere realizzati con il GVCS. Tutti i documenti OSE sono rilasciati sotto licenza Creative Commons attribution - share alike, che sigin ca che ogni utente Ă¨ libero di riprodurre, distribuire quella speci ca opera, di modi carla all'occorrenza e di utilizzarla per ni commerciali, a patto che venga reso esplicito che si tratta di un'opera derivata da OSE e che il prodotto derivato sia distribuito alla stessa maniera dell'originale.

Sorgente

Come accennato in precedenza, la sorgente Ă¨ il Global Villgae

Construction Set, un set di 50 macchinari che possono essere utilizzati per l'attivitĂ rurale. Le sorgente principali sono dunque tutti i disegni, le istruzioni di costruzione e dei montaggi dei vari macchinari (Figura 4.14). Il cuore

35 Il crowdfunding Ă¨ un sistema di nanziamento `dal basso'. Attraverso apposite piattaforme online, gli utenti possono presentare progetti di qualunque tipo e fare una richiesta aperta di nanziamento. Chiunque Ă¨ libero di partecipare al nanziamento: se entro una precisa data di scadenza saranno stati raccolti tutti i soldi necessari, all'utente promotore sarĂ riconosciuto il nanziamento richiesto.

4.3.

119

CASI STUDIO

Figura 4.14: Il Global Village Construction Set: in alto a destra gli strumenti per l'edilizia (fonte:

http://opensourceecology.org/).

della sorgente è costitutito dal Civilization Starter Kit

. Oltre ai macchi-

nari fanno parte della sorgente anche tutti i prodotti derivati dall'uso dei macchinari. La Microhouse è uno di questi, prodotto usando la pressa per i BTC (blocchi di terra compatta) e altri macchinari per lavorare il legno e impastare il cemento. Tutti i le sono disponibili in formato dxf e Sketchup, quindi leggibili e modi cabili con software liberi o gratuti.

Comunità

La comunità è composta da utenti e diversi gruppi professio-

nali e non: architetti, contadini, designer, ingegneri e appassionati. Si basa sull'idea che, dato un gruppo centrale di sviluppo presso la Factor E Farm, si possano poi sviluppare dei sotto gruppi in altre città o in altri paesi. Nel 2012 vi erano gruppi che collaboravano in altri 5 paesi oltre agli Stati Uniti (uno di questo è l'Italia) e altri gruppi che si concentravano sui prodotti derivati, in particolare la casa OSE, detta Microhouse, sviluppata in collaborazione con il gruppo di progettazione polacco Cohabitat (Figura 4.15).

36 http://opensourceecology.org/wiki/Civilization_Starter_Kit_DVD_v0.01

120

CAPITOLO 4.

ARCHITETTURA OPEN SOURCE

Figura 4.15: Schema sintetico della Microhouse (fonte:

wiki/OSE_Microhouse).

Piattaforma

http://opensourceecology.org/

OSE Ă¨ basata sul sistema del Wiki, analogamente a quanto

accade con Wikipedia. Ogni utente Ă¨ dunque libero di modi care, aggiungere o creare le voci presenti sul wiki OSE. Accanto a questo strumento vi Ă¨ il forum, il quale permette un confronto continuo tra tutti gli utenti sulle questioni che vengono proposte.

Business model

Come detto in precedenza, OSE si basa sul contributo

diretto degli utenti da un lato, di privati facoltosi dall'altro. Attraverso la promozione di una campagna di crowdfunding nel 2011 Ă¨ riuscita a mettere insieme piĂš di 60.00 dollari americani, ricevendo il plauso di molti `venture capitalist' e l'appoggio economico della Suttleworth Foundation

. Ancora oggi

Ă¨ possibile donare piccole o grandi somme direttamente dal sito dell'iniziativa.

Risultati

Oltre alla conduzione della `Factor E Farm' e alla continua co-

struzione di macchine, nel 2012 OSE contava 63 macchinari costruiti su una base di 16 modelli.

Di questi 63 macchinari, 13 sono stati costruiti al di

fuori della E Farm in 4 paesi di erenti in cui vi sono gruppi locali attivi sul

37 http://www.shuttleworthfoundation.org/

4.3.

121

CASI STUDIO

progetto. Il forum al momento ospita circa un migliaio di discussioni attive. Dal punto di vista dell'architettura è stato realizzato il primo prototipo

di Microhouse (Figura 4.16), la casa realizzata con i macchinari OSE

. Il

progetto è in fase di sviluppo ma tutti i materiali relativi (piante, sezioni, modelli tridimensionali) sono disponibili online.

Figura

4.16:

prototipo

Microhouse

costruito

opensourceecology.org/wiki/OSE_Microhouse).

Considerazioni generali

nel

2013

(fonte:

http://

Open Source Ecology è una piattaforma piut-

tosto vasta con varie ambizioni. Dal punto di vista dell'architettura, si sta concentrando sulla realizzazione di piccole unità abitative.

L'aspetto più

interessante è legato al Global Village Construction Kit: invece che fornire soluzioni già sviluppate e testate, OSE fornisce macchinari e strumenti, lasciando libera la sperimentazione dell'utente.

Ad esempio lo sviluppo di

Microhouse è stato possibile proprio perchè un gruppo di architetti polacchi (Cohabitat) ha sviluppato un progetto di casa partendo dai macchinari che

38 http://opensourceecology.org/wiki/OSE_Microhouse

122

CAPITOLO 4.

ARCHITETTURA OPEN SOURCE

OSE metteva a disposizione. L'ampiezza e la essibilitĂ del progetto permettono di inglobare facilmente diversi contributi e di avere realtĂ diverse che contribuiscono localmente allo sviluppo del progetto.

4.3.6 WikiHouse

Wikihouse Ă¨ una piattaforma collaborativa basata sullo sviluppo di strutture tridimensionali (anche di grandi dimensioni) partendo da elementi piani incastrati tra loro. Gli elementi possono essere facilmente realizzati grazie all'utilizzo di macchine a controllo numerico da diversi materiali (principalmente pannelli di legno multistrato, ma Ă¨ in studio l'utilizzo di altri materiali). Il nome dell'iniziativa Ă¨ piuttosto eloquente: la piattaforma intende sviluppare modelli abitativi (house) in maniera collaborativa (wiki). Wikihouse nasce da un progetto di open design, giĂ analizzato nel capitolo II, Open Desk. Da quella esperienza lo studio 00:/ Architecture ha portato avanti l'iniziativa (Figura 4.17).

Promotori

Il promotore principale Ă¨ lo studio di architettura 00:/ Archi-

tecture con sede a Londra.

I due promotori principali dell'iniziativa sono

Alastair Parvin e Nick Ierodiaconou.

Come funziona

Si tratta di una piattaforma di collaborazione fondata su

due elementi principali: da un lato un sistema costruttivo basato su elementi e telai piani interconnessi tra di loro; dall'altro un plugin per il software Sketchup che permette, da un modello tridimensionale comprendente tutti gli oggetti, di ricavare dei le che possono essere direttamente inviati a un macchina di taglio a controllo numerico (Figura 4.18). La particolaritĂ del sistema costruttivo risiede nella possibilitĂ di realizzare pezzi di dimensioni relativamente piccole che, uniti meccanicamente tra di loro, possono dare origine a un telaio di grandi dimensioni.

Il plugin di Sketchup (insieme

ai modelli che vengono distribuiti) consente invece di e ettuare operazioni piuttosto macchinose e complicate in modo automatico.

Data la piccola

dimensione dei pezzi ne consegue l'alto numero totale di elementi, i quali devono essere correttamente posizionati per il taglio all'interno di opportune sagome. Automatizzando questo processo si facilita il trasferimento di dati dal modello tridimensionale alla sua e ettiva realizzazione

39 In questo paragrafo si fa esplicitamente riferimento, ove non diversamente indicato, al sito web dei WikiHouse

http://www.wikihouse.cc/

ed alle informazioni contenute al

suo interno. Il sito Ă¨ stato consultato l'ultima volta nel novembre del 2013.

4.3.

123

CASI STUDIO

Figura 4.17: Lo schema che rappresenta lo sviluppo recente di WikiHouse: da OpenDesk (nella parte bassa dell'immagine) no alle ricerche attive in Nuova Zelanda, Brasile e Regno Unito (fonte:

http://www.wikihouse.cc/).

Processo di apertura

Tutto ciò che è contenuto su Wikihouse è ad accesso

libero: sia tutte le informazioni relative al processo costruttivo e progettuale, ovvero tutte le speci che tecniche del sistema costruttivo; sia il plug in di Sketchup, sviluppato nella stessa maniera con cui viene sviluppato il software open source (viene utilizzata la piattaforma Github

Sorgente

per il suo sviluppo).

La sorgente è composta da due elementi fondanti:

il sistema

costruttivo e lo strumento digitale che permette di utilizzarlo in fase progettuale. Il sitema costruttivo è, come detto, un sistema di telai piani (formati da piccole parti) interconnessi tra di loro. Il sistema di interconnessione, molto semplice ma non banale, può essere considerato come il cuore tecnologico del sistema. Utilizzando pannelli comuni (principalmente di multistrato, ma anche di altro materiale) si possono realizzare elementi di ridotte dimensioni. Il sistema costruttivo permette di realizzare oggetti (anche di grandi dimen-

40 https://github.com/

124

CAPITOLO 4.

ARCHITETTURA OPEN SOURCE

Figura 4.18: Il principio progettuale e costruttivo su cui si basa WikiHouse: dal modello virtuale condiviso con altri utenti si ottengono i piani di taglio, l'informazione viene trasmessa a un pantografo CNC che taglia i pezzi nella giusta misura, in ne la struttura viene facilmente assemblata (fonte:

trent-bank).

http://archinect.com/EricChancellor/project/

sioni) attraverso la combinazione di parti più piccole.

Il secondo elemento

che compone la sorgente è il software. Il software consente la gestione e l'uso del sistema costruttivo e al contempo permette agli utenti di interagire con la piattaforma.

Comunità

La comunità è composta perlopiù da architetti o makers. Sin

dal principio l'obiettivo dei promotori dell'iniziativa è stato quello di favorire la nascita di comunità locali in grado di agire su problematiche speci che. Ad oggi si contano gruppi attivi in 6 paesi: Inghilterra, Stati Uniti, Nuova Zelanda, Francia e Spagna e Brasile, e in alcuni di questi paesi sono attivi contemporaneamente più gruppi (Inghilterra e Stati Uniti soprattutto). L'apertura di una nuova sotto-comunità (o capitoli) avviene attraverso la rma di un `contratto' attraverso il quale i nuovi a liati si impegnao a rispettare le regole della comunità e a favorirne l'attività (Figura 4.19).

Piattaforma

La piattaforma di Wikihouse è composta da un sito web che

funge anche da repository di tutti i modelli sviluppati dagli utenti, e da un

4.3.

125

CASI STUDIO

Figura 4.19: Il `contratto' proposto dai promotori alle nuove sotto-comunitĂ , chiamate capitoli: una sorta di contratto etico e pratico che permette un libero utilizzo del materiale reso disponibile da WikiHouse e dai suoi a liati e favorisce la collaborazione tra le varie comunitĂ nazionali e locali (fonte:

plug in di Sketchup.

http://www.wikihouse.cc/).

Oltre a facilitare l'uso della sorgente, il plugin con-

sente una connessione diretta con il sito web, permettendo di scaricare o caricare all'interno del sito i modelli che si intendono sviluppare o che sono stati sviluppati, senza procedimenti intermedi. Tale stratagemma consente in maniera e cace di accrescere il numero di progetti realizzati. Vi sono poi tre gruppi di discussione, accessibili via email, che comprendono un gruppo generale, uno orientato alla costruzione e un terzo dedicato allo sviluppo del software.

Business model

Wikihouse si basa principalmente su donazioni. L'aper-

tura di una sede in Brasile Ă¨ stata possibile grazie alla dalla vittoria del premio TED The city 2.0, mentre lo sviluppo attuale Ă¨ e ettuato attraverso donazioni degli utenti, i quali possono nanziare uno dei seguenti aspetti: sviluppo del plugin, sviluppo della piattaforma, costruzione della prima casa WikiHouse completa.

126

Risultati

CAPITOLO 4.

ARCHITETTURA OPEN SOURCE

Dal punto di vista della comunità sono presenti al momento nu-

merosi capitoli paralleli, oltre a quello proposto dalla piattaforma principale. Ogni sotto-comunità parallela è stata in grado di produrre prototipi della sola struttura con la copertura, senza tamponamenti esterni. Attualmente è già

stato sviluppato il progetto per la casa completa Wikihouse

(Figura 4.20),

in fase di nanziamento.

Figura 4.20:

La casa completa WikiHouse.

L'immagine rappresenta l'ultima fase del

lavoro, la posa in opera dei telaio del piano superiore (fonte:

Considerazioni generali

http://www.wikihouse.cc/).

Wikihouse è forse la piattaforma che ha avuto

più successo, sia dal punto di vista mediatico che dal punto di vista di partecipazione globale.

La facilità di accesso alla sorgente e la sua intrinseca

semplicità hanno permesso un proliferare di iniziative in varie parti del mondo (Figura 4.21).

La sorgente è un semplice nodo strutturale tra elementi

piani, che permette di unire piccoli elementi per creare oggetti di dimensioni maggiori. Da semplici assi di legno opportunamente sagomate si può dunque ottenere un telaio strutturale complesso attraverso un montaggio piuttosto facile. Elementi principali e nodi sono realizzati con la stessa tecnica. L'innovazione di WikiHouse è quella di pensare un sistema di disegno e combinazio-

41 https://dl.dropboxusercontent.com/u/1850356/WikiHouse/WikiHouseUK_

50kHouse_v2.pdf

4.3.

127

CASI STUDIO

Figura 4.21:

Il padiglione realizzato per la World Maker Faire 2013 a New York.

struttura Ă¨ stata montata in un giorno e mezzo da utenti non esperti e utilizzata dal pubblico durante tutta la era (fonte:

http://www.wikihouse.cc/).

ne essenziale, all'interno del quale il trasferimento da disegno a produzione Ă¨ automatizzato dal software opportuno, anch'esso sviluppato all'interno della comunitĂ . Inoltre gli strumenti di interazione con la piattaforma sono decisamente avanzati e funzionali. L'organizzazione della comunitĂ in sottogruppi piĂš piccoli, che vanno dalla scala nazionale alla scala cittadina, permette agli utenti di confrontarsi nella propria lingua sulle questioni poste in essere dalla piattaforma e di sviluppare soluzioni in grado di rispondere a esigenze locali. Un esempio emblematico Ă¨ quello del gruppo Neozelandese che ha sviluppato in parallelo nodi e strutture antisismiche, scegliendo di concentrarsi su questo tema per l'elevata attivitĂ sismica delle isole del Paci co. WikiHouse ha subĂŹto uno sviluppo e un'evoluzione che continua nel tempo: infatti la piattaforma e il plugin di Sketchup sono in continuo sviluppo, come anche il modello di casa completa. In ne sono numerose le varianti e le realizzazioni e ettuate no ad oggi. Guardando gli schemi relativi a WikiHouse Ă¨ pressochĂ¨ immediato pensare al lavoro di Segal: la costruzione a telaio e l'orditura secondaria rimandano immediatamente alle case di Lewinsham. Tuttavia rispetto a Segal i promotori di WikiHouse sono riusciti a migliorare il proocesso costruttivo: hanno

128

CAPITOLO 4.

ARCHITETTURA OPEN SOURCE

eliminato la gura del carpentiere garantendo, attraverso l'uso di macchine a controllo numerico e del loro particolare giunto, la necessaria precisione dei pezzi che compongono la struttura e la necessaria facilitĂ di posa in opera.

4.4

Considerazioni generali

Dopo aver analizzato i sei casi studio si delinea un panorama piuttosto complesso e variegato.

CiĂ˛ non toglie che sia comunque possibile evidenzia-

re almeno alcuni aspetti fondamentali che emergono dall'analisi precedente e, come si vedrĂ nel prossimo capitolo, de nire alcuni strumenti operativi che possono essere utilizzati per mettere in pratica esperienze di Architettura Open Source. Volendo iniziare con una prima considerazione rispetto a quanto visto in occasione dell'analisi dei casi studio, si puĂ˛ a ermare quanto segue:

Laddove venga a

mancare uno di questi tre elementi l'Open Source si riduce a mera etichetta, e l'utilizzo del termine risulta forzato e fuorviante: slo grazie alla presenza di sorgente, comunitĂ e piattaforma Ă¨ possibile parlare di Architettura Open Source. Di seguito verranno prese in esame alcuni temi relativi alle e ettive possibilitĂ di applicazione dell'Architettura Open Source.

4.4.1 Temi e campi di applicazione Conviene innanzitutto partire dai temi a rontati dalle iniziative di Architettura Open Source e dai loro campi di applicazione. Analogamente a quanto accade nel mondo software, ogni iniziativa Open Source a ronta speci che tematiche.

Lo stesso avviene nel mondo dell'Open Design, dove ciascuna

iniziativa Ă¨ fortemente caratterizzata dal punto di vista dei temi e delle possibilitĂ di applicazione. Dai casi studio presi in esame emerge lo stesso: alcune caratterizzazioni tematiche prevalgono rispetto ad altre. Le tematiche dell'architettura per i paesi in via di sviluppo e dell'architettura per l'emer-

4.4.

129

CONSIDERAZIONI GENERALI

genza sono predominanti, sebbene altri temi stiano lentamente emergendo. Vista la natura recente di tali iniziative non Ă¨ ancora dato sapere se vi sarĂ un'evoluzione tale per cui l'Architettura Open Source sarĂ uno strumento valido per la produzione di case a basso costo nei prossimi decenni. Tuttavia Ă¨ forte la convinzione che, sebbene l'Architettura Open Source non sia un modello che possa essere sviluppato nell'immediato su larga scala, possa comunque avere la possibilitĂ di evolvere gradualmente, di adattarsi e misurarsi con temi e problematiche emergenti. L'Open Source in Architettura non Ă¨ solo un interessante strumento, ma si con gura come un processo di presa di coscienza, uno spostamento di pensiero e di vedute per quanto riguarda i principi di organizzazione della pratica architettonica e anche dell'autorialitĂ dell'architetto.

4.4.2 L'Architettura Open Source come strumento Uno dei pensieri che sta alla base del software open source Ă¨ che questo possa avere un utilizzo universale.

CiĂ˛ dovrebbe avvenire in seguito all'apertura

della sorgente, azione che permette a chiunque di e ettuare le necessarie modi che in modo da garantire al software la compatibilitĂ con piattaforme di erenti o di essere distribuito in forme e lingue diverse. Ogni singola sorgente di software open source Ă¨ oggetto di sviluppo da parte della propria comunitĂ attraverso la propria piattaforma. Ma come nasce una iniziativa Open Source? Come scriveva Eric S. Raymond nel suo libro La cattedrale e il bazaar, ogni buon lavoro software inizia dalla frenesia personale di uno sviluppatore. (Raymond 1998).

Ovvero la

necessitĂ Ă¨ la madre di tutte le invenzioni. Stallman costruĂŹ la de nizione del copyleft partendo dalla necessitĂ di avere a disposizione i driver delle stampanti del suo u cio. Linus Torvalds voleva invece avere un sistema operativo da modi care e, non essendocene uno disponibile, iniziĂ˛ a svilupparlo da sĂŠ. Grazie al sostegno di altri sviluppatori i loro progetti hanno raggiunto una maturitĂ e una a dabilitĂ inizialmente insperati e inimmaginabili. Nel mondo del software open source vi sono ad oggi migliaia di progetti con diversi temi e campi di applicazione, e all'interno di queste iniziative ciascun utente puĂ˛ svolgere diversi compiti. Nel caso dell'open design e dell'Architettura Open Source si riscontra lo stesso tipo di fenomeno.

Per esempio l'Open Architecture Network nasce

dalla necessitĂ di una grande associazione (Architecture for Humanity) di gestire meglio i propri progetti e di favorire la nascita di iniziative parallele e nuovi progetti. In un momento di cambio di scala, sia dal punto di vista del numero di progetti che delle entitĂ dei nanziamenti, AfH ha deciso di sviluppare una piattaforma di Architettura Open Source con la convinzione

130

CAPITOLO 4.

ARCHITETTURA OPEN SOURCE

che ciĂ˛ avrebbe facilitato il suo lavoro e l'e cacia dei suoi interventi. In altri casi da piccole frenesie personali si sono sviluppate interessanti iniziative: Ă¨ questo il caso di Martin Jakubowski, la cui passione per l'agricoltura, ma anche per per l'hacking, lo hanno portato a essere il principale promotore di Open Source Ecology. Invece WikiHouse nasce dal progetto degli arredi di un grande spazio di coworking nel centro di Londra (HUB Westminster): da tale esperienza nascerĂ prima Opendesk (di cui si Ă¨ giĂ parlato nel secondo capitolo) e in seguito Wikihouse, che approfondisce il sistema tecnologico alla base dell'esperienza precedente.

L'architettura Open Source non Ă¨ quindi un ne da perseguire, ma un potente strumento in grado di dare la possibilitĂ a chiunque di sviluppare progetti di architettura e di riplasmare il processo edilizio secondo le proprie necessitĂ . La maggior parte dei casi studio presi in considerazione si rifĂ esattamente a questo atteggiamento: l'Open Source diventa uno strumento non solo di condivisione (i promotori non sono dei benefattori, non regalano nulla) ma un potente strumento di sviluppo di un progetto che altrimenti sarebbe stato di cile e oneroso sviluppare.

Questo momento di `apertura' Ă¨ glio della

necessitĂ dei promotori i quali, per i motivi piĂš svariati, vedono nell'Open Source una risorsa enorme per portare avanti iniziative che altrimenti sarebbero destinate a scomparire o comunque a cessare di essere sviluppate. Il successo (o il fallimento) dell'iniziativa non Ă¨ quindi piĂš funzione della caparbietĂ e delle capacitĂ dei suoi promotori, ma diventa funzione della comunitĂ che riconosce il valore del progetto e contribuisce alla sua crescita e al suo sviluppo.

4.4.3 Oltre l'emergenza e i Paesi in via di sviluppo? Analizzando i diversi casi studio vanno evidenziati alcuni aspetti ricorrenti legati alle tematiche a rontate.

Infatti a partire dall'Open Architecture

Network la maggior parte delle esperienze riguardano temi generalmente ai margini del dibattito architettonico: l'architettura per l'emergenza e l'architettura nei paesi in via di sviluppo. OAN si concentra principalmente sull'architettura per l'emergenza e lo sviluppo (e non potrebbe essere altrimenti dal momento che AfH, l'organizzazione no pro t per cui Ă¨ stata sviluppata, si occupa principalmente di quei temi). Open Structures Ă¨ stata usata da Brussels Cooperation per un progetto in Congo; OpenSimSim ha fatto dell'esperienza OpenJapan la sua attivitĂ principale in seguito al sisma dell'11 marzo 2011 in Giappone; in ne Wikihouse Ă¨ in fase di sviluppo in Nuova Zelanda come soluzione abitativa d'emergenza post sisma (terremoto di Christchurch del

4.4.

CONSIDERAZIONI GENERALI

131

22 settembre 2011) e in Brasile (a Rio de Janeiro) come soluzione abitativa a basso costo per le favelas della cittĂ brasiliana. Quali sono le ragioni che fanno sĂŹ che la maggioranza delle esperienze prese in considerazione si riferiscano a speci che tematiche? In primo luogo conviene riprendere le conclusioni del precedente paragrafo. L'Architettura Open Source Ă¨ un mezzo, uno strumento che permette di a rontare alcuni temi progettuali. Ă&#x2C6; uno strumento che ha alcune caratteristiche, prima di tutte la libertĂ di essere usato, oltre al fatto di non essere sottoposto a vincoli contrattuali ed economici (se non quelli imposti dalla licenza d'uso, che perĂ˛, per sua stessa natura, tende a favorirne l'uso piuttosto che limitarlo). Proprio questa condizione ne permette (e ne agevola) l'utilizzo in situazioni diverse dalla normale pratica professionale, come ad esempio l'intervento d'emergenza o nei paesi in via di sviluppo. Infatti in tali situazioni i rapporti vigenti nel processo edilizio tra gli attori coinvolti non solo non sono sanciti da vincoli contrattuali ma si presentano meno de niti, piĂš sfocati, a volte ribaltati e magari apparentemente confusionali e l'utente nale puĂ˛ anche trasformarsi in sviluppatore. Oltre a ciĂ˛ la carenza di risorse (di ogni genere) spinge verso soluzioni non tradizionali, essibili e agili. In secondo luogo, e in conseguenza di quanto detto nora, l'assenza totale o parziale di norme restrittive nell'ambito dell'informale o dell'emergenza facilita l'utilizzo di strumenti e soluzioni frutto di uno sforzo collaborativo, e quindi non de nite a priori. Verrebbe dunque da pensare che l'applicazione dell'Architettura Open Source possa avvenire unicamente in ambienti e contesti informali, all'interno dei quali la libertĂ di azione degli utenti permette di innescare processi progettuali ed edilizi di tipo non tradizionale, nei quali l'esito nale del processo non deve rispondere a vincoli normativi ma esclusivamente alle necessitĂ degli utenti stessi.

Infatti dalla lettura dei casi studio sembra di cile

che l'Architettura Open Source possa applicarsi nei casi in cui la comunitĂ e l'utente nale si debbano confrontare con degli attori (ad esempio con l'amministrazione pubblica) le cui richieste in termini normativi poco si adattano a un processo piuttosto informale.

Banalmente, puĂ˛ sembrare di cile che

un singolo cittadino possa disegnare la sua casa usando le risorse messe a disposizione da WikiHouse senza doversi rivolgere a un tecnico quali cato, proporre il progetto all'u cio tecnico di zona, vederselo approvare (o meno), ottemperare a tutte le norme vigenti, consegnare le necessarie asseverazioni o quant'altro. Non Ă¨ dunque unicamente un problema di passaggio dal bit all'atomo, ovvero da sorgente digitale a oggetto sico, ma Ă¨ anche un problema di passaggio da un processo informale, basato sulla reputazione dei singoli componenti e sul lavoro collettivo, a un processo all'interno del quale i vincoli burocratici, normativi e tecnici sono una componente assolutamente non tra-

132

CAPITOLO 4.

ARCHITETTURA OPEN SOURCE

scurabile. Ma un processo come quello che viene innescato dall'Architettura Open Source deve essere applicato unicamente in un contesto ugualmente `open source', ovvero un contesto in cui i vincoli sociali, normativi e tecnici non sono un ostacolo?

4.4.4 PossibilitĂ e ettive di applicazione Per confutare quello che potrebbe essere considerato un limite oggettivo dell'Architettura Open Source, Ă¨ necessario evidenziare come altri processi analoghi abbiano potuto avere luogo anche in contesti molto esigenti dal punto di vista normativo. In questo senso Ă¨ molto interessante risottolineare il rapporto che Christopher Alexander ebbe con le istituzioni, ovvero l'aspetto burocratico di tutto il processo da lui proposto. Infatti non solo il processo costruttivo era radicalmente alternativo alla pratica comune, ma lo era anche per quanto riguarda il sistema di norme e regolamenti all'interno del quale si sarebbe dovuto espletare: In alcuni casi inoltre la di coltĂ di applicazione del linguaggio dei pattern consiste nella presentazione di un processo de nitivo ed esecutivo presso un'amministrazione pubblica.[...]Alexander risolse il problema ottenendo il permesso governativo per un processo costruttivo speci co (ossia per un insieme di operazioni con parametri chiaramente de niti), che consente la generazione di risultati simili ma distinti. I risultati di un tale processo furono approvati automaticamente senza bisogno di autorizzazioni. Risulta quindi importante ottenere l'approvazione dalle autoritĂ preposte per il processo piuttosto che per una serie di disegni nali (Silvestri 2009). Altro esempio Ă¨ quello di Elemental di Alejandro Aravena. Il progetto di Aravena, che si pone l'obiettivo di realizzare abitazioni a basso costo, prevede l'iniziale realizzazione di una struttura in grado di fornire il minimo indispensabile agli abitanti, in termini di super cie disponibile e servizi connessi.

La struttura prevede perĂ˛ che l'abitante, secondo le sue necessitĂ e

la sua disponibilitĂ economica, possa successivamente ingrandire la sua abitazione andando a realizzare volumi aggiuntivi.

Tale operazione Ă¨ lasciata

all'utente (seppur con dei vincoli strutturali precisi) e puĂ˛ portare a diversi risultati, sia in termini volumetrici che formali e materici. L'aumento di volume Ă¨ quindi incentivato nei limiti imposti dal progetto stesso: grazie ai laboratori di appoggio tecnico e progettuale coordinati dagli architetti di Elemental, gli abitanti, coinvolti anche nella fase di progettazione in un articolato dialogo partecipativo, hanno iniziato un processo di ampliamento e modi cazione delle architetture e degli spazi del quartiere: preservando i caratteri del progetto architettonico originario, gli interventi di completamento vanno dall'integrazione di elementi di arredo, all'assemblaggio di frammenti

4.4.

133

CONSIDERAZIONI GENERALI

delle vecchie case, no a interventi piĂš complessi di ampliamento, similmente ad altre esperienze di architettura residenziale sovvenzionata in America Latina (il quartiere El Tigral a BogotĂĄ di RenĂŠ Carrasco o gli interventi a Cabo Frio, Rio de Janeiro). (Gallanti 2005). Anche Wikihouse sta facendo esattamente questo: nel processo attuale di maturazione dell'iniziativa si sta tentando di passare da un ottimo sistema costruttivo per padiglioni temporanei o di emergenza (si possono vedere le esperienze americane e neozelandesi) a un sistema e cace per l'autocostruzione della casa, con evidenti riferimenti a Walter Segal dal punto di vista costruttivo ma anche concettuale. Non Ă¨ un caso infatti che uno dei promotori, Alastair Parvin, sia coautore di una interessante pubblicazione sul tema del diritto alla costruzione (A right to build, 2011) all'interno della quale il rapporto tra pubblico e autocostruttore privato viene ampiamente a rontato: the most innovative and powerful means for Local Authorities to pursue a sustainable, a ordable housing agenda on lean resources would be to `create' a new class of land speci cally designated for self-provision only. This would begin simply by including self-provided housing as a recognised class of development in their Strategic Housing Market Assessments

(Parvin, Saxby,

Cerulli & Schneider 2011, p.62).

Il progetto di Architettura Open Source non deve proporre unicamente un metodo innovativo e accessibile di passaggio da informazione digitale a materia sica, da bit ad atomo, ma deve anche sforzarsi di sviluppare sistemi adeguati di passaggio da un processo creativo informale a un contesto costruttivo anche fortemente normato.

42 Il mezzo piĂš e cace e innovativo che le autoritĂ locali hanno per perseguire un programma di housing sostenibile e accessibile (in un regime di scarsitĂ di risorse) Ă¨ quello di de nire una nuova categoria di uso del suolo, speci catamente progettata per ospitare case in autocostruzione.

Questa operazione puĂ˛ essere fatta semplicemente includendo

le abitazioni autocostruite negli interventi riconosciuti nelle Valutazioni Strategiche del Mercato Edile. [traduzione italiana a cura dell'autore].

Parte III Strumenti operativi dell'Architettura Open Source

135

137

Participation in design is not a new thing in the history of architecture, and every recurrence of this very old notion elicits a variety of misgivings and fears, old and new alike.

Unlike texts, images or

music, buildings are not media objects; as we are told and reminded time and again, reinforced concrete is not as malleable as a webpage, hence we cannot realize a collaborative architecture as easily as a collaborative, on-line encyclopedia. This is of course a truism, but it is not necessarily true.

(Carpo 2009a)

La terza parte di questa discussione Ă¨ volta a de nire gli strumenti operativi dell'Architettura Open Source e a illustrarne il funzionamento in caso di utilizzo. In seguito all'analisi dei casi studio Ă¨ stato possibile costruire un insieme di dispositivi progettuali che possono essere di supporto nel processo di de nizione delle tre componenti dell'Architettura Open Source: la sorgente, la comunitĂ e la piattaforma. Suddivisi in questi tre macrotemi verranno proposte delle buone pratiche per la costruzione di una iniziativa progettuale che voglia adottare il metodo di sviluppo Open Source. Al ne di veri carne il funzionamento viene anche presentata una iniziativa sperimentale svoltasi al Politecnico di Torino.

Si Ă¨ trattato di un workshop semestrale propo-

sto agli studenti delle lauree specialistiche in architettura del Politecnico di Torino, all'interno del quale gli strumenti operativi dell'Architettura Open Source sono stati adottati e utilizzati. L'iniziativa in questione, denominata Brickshell, ha visto la partecipazione di una trentina di persone tra studenti, docenti, tecnici e simpatizzanti ed Ă¨ stata un'interessante occasione per osservare da vicino e toccare con mano molti dei fenomeni che sono stati descritti nelle pagine precedenti. Si Ă¨ trattato di un processo edilizio completo, dalla progettazione alla costruzione e al mantenimento di un piccolo edi cio realizzato all'interno del campus del Politecnico di Torino. La de nizione degli strumenti operativi dell'Architettura Open Source e la loro messa in opera permette, in conclusione, di fare un'ulteriore ri essione circa il fenomeno qui a rontato: oltre alla de nizione degli strumenti operativi, quali altre azioni

43 La partecipazione nella progettazione non Ă¨ cosa nuova per la sotria dell'architettura, e ogni ritorno di questa vecchia nozione provoca una seire di dubbi e paure, vecchie e nuove. A di erenza dei testi, delle immagini o della musica, l'architettura non Ă¨ composta da oggetti mediali; come abbiamo detto e ricordato piĂš e piĂš volte, il cemento armato non Ă¨ malleabile come una pagina web, perciĂ˛ non siamo in grado di realizzare una architettura collaborativa cosĂŹ come realizziamo una enciclopedia collaborativa on-line. Questo Ă¨ certamente vero, ma non Ă¨ necessariamente una veritĂ . [traduzione italiana cura dell'autore].

138

debbono essere compiute a nchĂŠ si crei la convergenza culturale necessaria per fare sĂŹ che l'Architettura Open Source esca dal limbo dell'informalitĂ per approdare a uno status di pratica comune normalmente riconosciuta?

Capitolo 5 Strumenti operativi 5.1

Il progetto della sorgente Da studente, Segal non sopportava l'immagine riduttiva del Modernismo dei semplici disegni a tratto, le super ci banali tipo cartone o in lucido cromo e vetro, ma era ancor più sconcertato dal fatto che i progetti da cui nascevano fossero così imprecisi, incomprensibili. A lui interessava un modo di costruire comprensibile, che si potesse capire e quindi prevedere, calcolare. Non c'è complicazione nella carpenteria comprensibile, ben calcolata , diceva più tardi. Nel suo libro Anarchy in Action, Colin Ward, parlando del tipo di prodotto che servirebbe in una società anarchica , suggerisce oggetti dal funzionamento trasparente; prodotti che abbiano chiarezza di funzionamento e di riparazione .

(McKean 1986, p. 23)

Si è visto come la sorgente (nel caso del software codice sorgente) e la sua apertura siano l'aspetto fondamentale di tutto il discorso legato all'Open Source. È un dato di fatto che sul web vi siano comunità e piattaforme collaborative di ogni genere e tipo, perlopiù di discussione e confronto, ma senza la de nizione chiara di una sorgente (sia essa progettuale, codice sorgente o di altro tipo) non è possibile parlare di Open Source. Il momento di de nizione della sorgente è dunque il momento cardine attraverso cui l'iniziativa Open Source prende forma e comincia a svilupparsi. Nel caso dell'architettura in particolare, e dell'Open Design in generale, la sorgente, per essere e cacemente implementata, deve avere alcune caratteristiche, le quali verranno illustrate nel prosieguo del paragrafo.

139

140

CAPITOLO 5.

STRUMENTI OPERATIVI

5.1.1 Sorgente uguale apertura La prima caratteristica Ă¨ data dall'apertura. PotrĂ sembrare banale ma senza apertura della sorgente non Ă¨ possibile parlare di Open Source (che signi ca appunto sorgente aperta). Se nel caso del software ciĂ˛ Ă¨ piuttosto facile (il codice sorgente Ă¨ un testo, scritto attraverso una sintassi particolare, propria del linguaggio di programmazione, ma Ă¨ e rimane comunque un testo) dal momento che la distribuzione libera della sorgente prevede quasi automaticamente l'apertura della stessa (basta avere un editor appropriato facilmente reperibile e conoscere il linguaggio di programmazione, indipendentemente dal fatto che il linguaggio di programmazione sia sviluppato in maniera Open Source o meno), nel caso del design e dell'architettura questa operazione non Ă¨ a atto scontata. Pensando a un progetto di architettura canonico, la sorgente Ă¨ composta da disegni esplicativi. I disegni sono di tipo tecnico e possono essere fatti in modo da essere letti in maniera pressochĂŠ universale. Il disegno su carta (o per estensione in formati che non ne permettano la modi ca) ha un grado di apertura piuttosto basso, poichĂ¨ per essere modi cato si deve agire su un altro supporto ridisegnando l'originale con le modi che che si vogliono e ettuare

. Tuttavia il disegno, nell'era digitale, puĂ˛ essere distribuito in un

formato modi cabile (il cosiddetto formato nativo, per esempio un le cad). Il grado di facilitĂ della modi ca Ă¨ funzione del tipo di disegno: un modello in 3d sarĂ piĂš facilmente comprensibile di un disegno in due dimensioni; un modello virtuale tridimensionale controllabile attraverso pochi comandi o parametri sarĂ piĂš comprensibile e utilizzabile di un semplice modello in tre dimensioni; se modulare la sorgente sarĂ piĂš facilmente governabile; se dotata di metadati (o semplici istruzioni) circa il suo funzionamento sarĂ ancora piĂš semplice da utilizzare e cosĂŹ via. Se oltre alla distribuzione libera della sorgente corrisponde anche un e ettivo processo di apertura della stessa (nel tentativo di replicare la semplicitĂ di modi ca ed editabilitĂ che avviene in campo software) Ă¨ possibile a ermare che si tratta a tutti gli e etti di Architettura Open Source. Esistono dunque diversi gradi di apertura: piĂš l'apertura di ogni parte della sorgente sarĂ garantita, piĂš l'iniziativa presa in esame riesce a replicare a tutti gli e etti un processo di sviluppo Open Source.

Volendo arrivare a una generalizzazione, una iniziativa di Architettura Open Source puĂ˛ dirsi tale non soltanto se la sorgente Ă¨ di-

1 Ovviamente se protetto da diritto d'autore il disegno Ă¨ assolutamente non modi cabile o copiabile in nessuna sua parte senza l'assenso del suo autore, ma qui prevale l'ipotesi che sia distribuito liberamente o comunque sotto opportune licenze, ad esempio di tipo Creative Commons.

5.1.

IL PROGETTO DELLA SORGENTE

141

stribuita liberamente, ma se essa, per sua stessa natura, favorisce la modi ca e l'implementazione da parte di altri utenti, anche non esperti. Per ottemperare a questa condizione vi sono varie possibilitĂ , ad esempio rendere la sorgente altamente modulare, facilitando l'implementazione o sviluppando apposite interfacce per utenti poco esperti, favorire la gestione della sorgente attraverso la parametrizzazione della stessa o semplicemente produrre una buona, chiara ed esaustiva documentazione.

5.1.2 Ricombinazione e modularitĂ Per favorire l'e ettiva apertura della sorgente e incentivare un lavoro proli co da parte degli utenti, molti dei casi presi in esame hanno adottato sorgenti altamente modulari favorendo le possibilitĂ di ricombinazione e interconnessione tra le parti progettate. Ă&#x2C6; questo il caso di iniziative come Wikihouse e OpenStructures le quali, prima ancora di proporre degli oggetti completi e niti (come ad esempio fanno Open Source Ecology o l'Open Architecture Network) propongono dei sistemi di assemblaggio basati su moduli ricorrenti e standard dimensionali piuttosto rigidi. In Open Structures questo approccio Ă¨ molto chiaro: la sorgente stessa Ă¨ una griglia dimensionale a cui ogni oggetto progettato, disegnato e prodotto, deve necessariamente riferirsi, pena la non compatibilitĂ con i pezzi prodotti dal resto della comunitĂ . Quello che a prima vista potrebbe sembrare un approccio piuttosto rigido al processo di sviluppo, si rivela invece essere il fautore della essibilitĂ intrinseca dell'iniziativa: attraverso l'uso di moduli ricorrenti e standard dimensionali Ă¨ possibile attuare un continuo processo di ricombinazione tra le parti, dal momento che la modularitĂ di ogni singolo pezzo consente e prevede la connessione con altri pezzi giĂ sviluppati. Esattamente come succede in un gioco

come il Lego o il Meccano , dove ogni pezzo puĂ˛ interconnettersi con un altro contribuendo a costruire nuove strutture, in OpenStructures si veri ca lo stesso fenomeno. Se perĂ˛ il Lego e il Meccano hanno dei set niti di oggetti disponibili, in OpenStructures ciascun utente puĂ˛ sviluppare il proprio pezzo in relazione alle sue necessitĂ , mettendolo poi a disposizione della comunitĂ

2 LommĂŠ fa espressamente riferimento al Meccano: The OS (OpenStructures) project explores the possibility of a modular construction model where everyone designs for everyone on the basis of one shared geometrical grid. It initiates a kind of collaborative Meccano to which everybody can contribute parts, components and structures. (LommĂŠe 2009) trad.: Il progetto OpenStructures esplora la possibilitĂ di una costruzione modulare dove tutti progettano per tutti su di una griglia condivisa. Innesca una specie di Meccano collaborativo a cui chiunque puĂ˛ contribuire con pezzi, parti, componenti e strutture. [traduzione italiana a cura dell'autore].

142

CAPITOLO 5.

STRUMENTI OPERATIVI

e aumentando esponenzialmente il numero di pezzi totali e le possibilitĂ di ricombinazione tra le parti. Analogo discorso puĂ˛ essere fatto per Wikihouse, dove il giunto base (una riproposizione della connessione a dardo di Giove usata comunemente nelle carpenterie lignee) diviene l'elemento principe di tutte le composizioni e la modularitĂ delle strutture (basata sulla dimensione dei pannelli comunemente disponibili) favorisce un utilizzo della sorgente anche da parte di non esperti e semplici appassionati.

La presenza di dimensioni standard e moduli ricorrenti diventa un e cace strumento progettuale, che, al contrario di quanto si potrebbe pensare, non favorisce la ripetitivitĂ ma esalta le differenze tra le varie soluzioni sviluppate in seguito all'attivitĂ di ricombinazione delle parti. Come visto nel primo capitolo, modularitĂ e ricombinazione non sono caratteri speci ci dell'Architettura Open Source ma caratteri fondativi di tutta l'attivitĂ presente su Internet e Web, da cui l'Architettura Open Source necessariamente attinge per favorire il suo stesso funzionamento.

5.1.3 Dal bit all'atomo Nel secondo capitolo si Ă¨ visto come la maggior parte delle iniziative di open design preveda l'utilizzo di macchine a controllo numerico o stampanti 3D per la realizzazione di vari oggetti. Nel caso del passaggio da informazione digitale a materia sica, nel mondo del design si tende a fare ricorso a macchine comandate da computer per realizzare gli oggetti o parti di oggetti, lasciando poi all'utente il compito di assemblare le varie parti (nel caso l'oggetto nale sia composto da piĂš parti). CiĂ˛ avviene per diversi motivi. Il primo si spiega con il fatto che attraverso la fabbricazione digitale Ă¨ possibile gestire e realizzare forme complesse, cosa che con le tecniche tradizionali o risulta troppo di cile o troppo costoso (e in alcuni casi entrambe le cose). Il secondo motivo Ă¨ legato a questioni relative alle tolleranze: attraverso la fabbricazione digitale, se il progetto Ă¨ stato ben realizzato Ă¨ possibile ottenere degli oggetti perfetti, ovvero degli oggetti che in termini dimensionali non presentano errori o di erenze rispetto al progetto (o presentano variazioni del tutto trascurabili). Nel caso di oggetti di design, in cui la tolleranza Ă¨ piuttosto bassa, la fabbricazione digitale contribuisce a rendere il problema della tolleranza un problema di secondo piano. Bisogna inoltre aggiungere una ri essione: la fabbricazione digitale di oggetti di piccola scala Ă¨ veloce ed economica, dunque Ă¨ possibile usare le stesse macchine per e ettuare operazioni di prototipazione rapida, andare cioĂ¨ a veri care immediatamente il funzionamento (o il malfunzionamento) di ciĂ˛ che si Ă¨ disegnato. Fatta questa veri ca, aggiustato il disegno in formato digitale e distribuitolo al-

5.2.

143

IL PROGETTO DI GESTIONE DELLA COMUNITÀ

l'interno della comunità, tutte le successive realizzazioni saranno pressoché a prova di errore. Nelle esperienze di Architettura Open Source vale lo stesso discorso, ma questo non esclude altri tipi di approccio.

Dato un control-

lo delle tolleranze radicalmente diverso (al crescere della scala diminuisce la tolleranza) è anche possibile prevedere degli approcci decisamente più tradizionali.

Infatti Open Architecture Network e Open Source Ecology (ma

anche OpenStructures) propongono dei sistemi costruttivi tradizionali, il cui controllo dal punto di vista della qualità nale è lasciato in mano a chi si occupa della realizzazione degli elementi e della costruzione degli edi ci o, nel caso di OpenStructures, a chi si occupa del corretto utilizzo di un sistema di riferimento comune a tutti i pezzi prodotti. Invece Wikihouse si concentra sulla produzione dei componenti grazie all'utilizzo di pantogra a controllo numerico (tendenzialmente a basso costo, come ad esempio il pantografo

CNC blackFoot, che costa intorno ai 3200 dollari americani ).

Il sistema

costruttivo di Wikihouse è di tipo tradizionale ed è infatti equiparabile al metodo Segal. Ma se nel metodo Segal era necessaria la presenza di un bravo carpentiere, in Wikihouse è unicamente necessaria la presenza di una fresa a controllo numerico. Ciò che per Segal veniva fatto dal carpentiere, il quale attraverso la sua capacità tecnica realizzava manufatti a regola d'arte, in Wikihouse ciò viene perfettamente realizzato dalle macchine a controllo numerico, riducendo drasticamente la possibilità di errori in fase di montaggio o la necessità di aggiustaggi di sorta. L'utilizzo o meno di macchine a controllo numerico non è tuttavia un carattere predominante dell'architettura Open Source, la quale si concentra sull'utilizzo di strumenti digitali in fase di progettazione più che in fase di realizzazione.

L'uso di strumenti digitali è motivato dal fatto che con

essi si produce informazione digitale la quale, grazie agli attuali mezzi di comunicazione, diviene facilmente distribuibile, modi cabile e condivisibile.

Nel passaggio da bit ad atomo non è dunque obbligatoria la fabbricazione digitale, tuttavia devono sempre essere previsti adeguati strumenti (tendenzialmente digitali) volti a facilitare il passaggio da bit a atomo, riducendo la possibilità di errore in fase di esecuzione. 5.2

Il progetto di gestione della comunità Per essere e ciente e andare incontro ai bisogni umani che pure determina, un nuovo sistema di produzione deve ritrovare la dimensione personale e comunitaria. La persona, la cellula di base congiungono in maniera ottimale l'e cacia e l'autonomia: soltanto sulla loro sca-

3 http://buildyourcnc.com/blackFoot48v40.aspx

144

CAPITOLO 5.

STRUMENTI OPERATIVI

la si puĂ˛ determinare il bisogno umano la cui produzione sociale Ă¨ realizzabile.

(Illich 1974)

La comunitĂ Ă¨ l'anima del progetto di Architettura Open Source, senza la quale esso non si puĂ˛ sviluppare. Ă&#x2C6; formata da tutte quelle persone che si interessano al progetto e che contribuiscono a svilupparne la sorgente. La comunitĂ , al pari della sorgente, Ă¨ oggetto di progetto, ovvero Ă¨ oggetto di attenzione progettuale da parte del promotore dell'iniziativa. Ovviamente non Ă¨ possibile progettare le relazioni che intercorrono all'interno della comunitĂ , ma Ă¨ comunque possibile mettere a punto alcuni strumenti a nchĂŠ suddette relazioni possano avvenire nella maniera piĂš proli ca possibile. Infatti data la natura complessa dell'operazione, esiste il rischio che la comunitĂ trasformi il dibattito e il lavoro sulla sorgente in una babele di informazioni che farebbero piombare nel caos l'intera iniziativa e ne limiterebbe le possibilitĂ di evoluzione. Per evitare ciĂ˛, attraverso alcune tecniche Ă¨ possibile fare in modo che la comunitĂ diventi la risorsa principale del progetto, che si autoorganizzi e cacemente per costituire una intelligenza collettiva in grado di a rontare le tematiche e i problemi che si presentano man mano che il lavoro sulla sorgente procede.

5.2.1 Figure e ruoli La comunitĂ Ă¨ formata da tutti gli utenti che partecipano al progetto di Architettura Open Source. A seconda del grado di partecipazione e contribuzione Ă¨ possibile distinguere di erenti ruoli. La gura piĂš importante Ă¨ quella del promotore (o dei promotori), ovvero di coloro che progettano e disegnano la sorgente e la rendono pubblica.

In caso di comunitĂ molto piccole essi

ricoprono il ruolo di animatori della comunitĂ , occupandosi di organizzare l'intero lavoro collaborativo e piani cando gli sviluppi futuri. Normalmente la loro reputazione Ă¨ decisamente alta all'interno della comunitĂ e non solo, dal momento che spesso si occupano di promuovere la loro iniziativa anche al di fuori di Internet e dei network sociali. In caso di comunitĂ molto grandi o suddivise localmente esistono degli utenti che svolgono il compito di animare e gestire le sotto comunitĂ regionali.

Svolgono gli stessi compiti dei

promotori o dei gestori globali ma su scala locale, favorendo la distribuzione e lo sviluppo locale della sorgente e dei progetti a essa correlati.

L'utente

base, il semplice sviluppatore, Ă¨ colui che partecipa alle iniziative proposte e contribuisce attraverso il suo lavoro allo sviluppo del progetto. Partecipa attivamente alle discussioni interne alla comunitĂ attraverso i canali predisposti e promuove personalmente, attraverso i suoi personali network sociali,

5.2.

145

IL PROGETTO DI GESTIONE DELLA COMUNITĂ&#x20AC;

le attivitĂ dell'iniziativa.

Il sostenitore Ă¨ una ulteriore gura:

si parla di

sostenitore principalmente in relazione al sostegno economico, il quale viene elargito in seguito a una richiesta di donazioni o a una speci ca campagna di fund raising (principalmente attraverso il crowdfunding). Egli puĂ˛ essere un utente attivo della comunitĂ , un esterno o un semplice simpatizzante. In ultimo vi sono tutti gli utenti i quali, pur non partecipando in maniera attiva alle discussioni, si interessano alle attivitĂ della comunitĂ e, direttamente o indirettamente, le promuovono attraverso i propri network sociali. Nello speci co, la comunitĂ utilizza diversi metodi per portare avanti la propria attivitĂ .

In questo paragrafo si prenderanno in considerazione

unicamente gli strumenti che permettono la comunicazione tra gli utenti, mentre tutto ciĂ˛ che riguarda la produttivitĂ degli utenti sarĂ a rontato nel prossimo paragrafo dedicato alla piattaforma. Campo indiscusso di azione delle comunitĂ open source e delle comunitĂ di Architettura Open Source sono i network sociali.

Questi vengono

utilizzati unicamente per promuovere l'attivitĂ della comunitĂ e non come luogo di incontro e dibattito (seppur virtuale), dal momento che non sempre garantiscono la necessaria privacy degli utenti ma, di contro, permettono di promuovere e far conoscere le attivitĂ a un numero piuttosto elevato di persone raggiungendo anche potenziali nuovi utenti. Le discussioni della comunitĂ vengono e ettuate attraverso appositi strumenti riservati agli utenti, i quali vi accedono previa registrazione. Gli strumenti sono perlopiĂš gruppi di discussione (o mailing list) e forum dedicati. L'obiettivo Ă¨ dunque quello di permettere agli utenti di seguire unicamente le discussioni a cui sono interessati e tralasciare il resto, orientando le risorse in funzione dell'interesse che gli argomenti di discussione suscitano negli utenti. Gruppi di discussione e forum sono moderati da speci ci utenti che governano la discussione garantendone l'utilitĂ e il prosieguo.

Si puĂ˛ a ermare che la comunitĂ Ă¨ composta da tutti gli utenti che partecipano a una iniziativa di Architettura Open Source in maniera attiva o indiretta.

5.2.2 Auto-organizzazione e autorialitĂ Il rapporto tra gli utenti, oltre alla presenza di ruoli (anche ben de niti) Ă¨, come in tutti i fenomeni di produzioni tra pari (p2p production) basato sulla reputazione. CiĂ˛ signi ca che il ruolo di un utente all'interno della comunitĂ non sarĂ dovuto a meriti o diritti ancestrali, ma dipenderĂ unicamente dal riconoscimento del suo lavoro da parte degli altri utenti. Questo fenomeno Ă¨ molto importante poichĂŠ si potrebbe pensare che l'attivitĂ all'interno di una comunitĂ di pari porti all'automatico annullamento dell'entitĂ autoriale

146

CAPITOLO 5.

STRUMENTI OPERATIVI

di ciascun utente in favore di una non meglio de nita `intelligenza collettiva' o `comunitĂ virtuale'. Infatti non mancano critiche alla produzione tra pari che tendono a considerare le comunitĂ di produzione orizzontale come delle specie di aziende che sfruttano il lavoro gratuito degli utenti per il proprio tornaconto, e si appropriano di ciĂ˛ che viene prodotto dall'utente senza che questo venga retribuito.

Se questo puĂ˛ essere vero per quanto riguarda i

social network o altri fenomeni nati sulla rete, per ciĂ˛ che riguarda la produzione sociale orizzontale tali a ermazioni risultano false, ed Ă¨ proprio il sistema di comunitĂ e di lavoro basato sulla reputazione, per sua intrinseca natura, che ci o re la possibilitĂ di confutare tali obiezioni. Un sistema basato sulla reputazione come unico metro di giudizio tende infatti a riconoscere gli sforzi di ciascun utente, inquadrandoli all'interno di un progetto condiviso: l'utente e il suo lavoro non vengono fagocitati dalla comunitĂ , ma bensĂŹ accolti e valorizzati all'interno della stessa. Proprio perchĂŠ basate sulla reputazione, all'interno delle comunitĂ si analizza e si controlla il lavoro di tutti, facendo modi che e correzioni dove necessario, o sostenendo il lavoro dello sviluppatore con consigli e incoraggiamenti. CiĂ˛ comporta un riconoscimento automatico del lavoro e delle porzioni di progetto sviluppate da quello speci co utente, e tale riconoscimento permette di risalire sempre al singolo utente/autore, ovvero di sapere chi ha fatto cosa (come ad esempio all'interno di Wikipedia, dove Ă¨ possibile risalire a tutti gli utenti che hanno modi cato una pagina). PerciĂ˛ la comunitĂ non Ă¨ un'entitĂ che o usca l'individuo e il suo lavoro, bensĂŹ l'unico strumento attraverso il quale il lavoro di ciascun utente puĂ˛ essere valutato e riconosciuto. I nuovi mezzi di comunicazione si basano, come visto in precedenza, su una fase iniziale di enunciato da parte dei singoli utenti a cui succede una fase di riconoscimento (positivo o negativo) da parte di tutti gli altri utenti della comunitĂ . Attraverso questi mutui scambi l'enunciato o si consolida o si annulla, e dopo il suo consolidamento viene distribuito e reso accessibile. Senza la fase di riconoscimento la comunitĂ non esisterebbe poichĂŠ vi sarebbero innumerevoli enunciati senza feedback, invece attraverso il riconoscimento la comunitĂ si struttura in gure e ruoli che si consolidano attraverso il meccanismo della reputazione. Per quanto concerne i casi studio presi in esame, Ă¨ molto facile trovare conferme di quanto spiegato, dato che ciascuna iniziativa dĂ la possibilitĂ ai nuovi utenti di sapere esattamente chi Ă¨ l'autore di ciascuna parte del progetto di Architettura Open Source. Ogni caso studio ha infatti sviluppato appropriati strumenti di accreditamento visibili da tutti gli utenti, senza citare il fatto che ogni attivitĂ di ciascun utente all'interno della piattaforma (inserimento di dati, caricamento di le, modi ca di testi) viene opportunamente registrata sui database della piattaforma stessa.

Il lavoro di ciascun utente viene registrato all'interno della piat-

5.2.

IL PROGETTO DI GESTIONE DELLA COMUNITĂ&#x20AC;

147

taforma e viene riconosciuto all'interno della comunitĂ , la quale ne valuterĂ la portata e ne garantirĂ la corretta distribuzione.

5.2.3 Organizzazione modulare della comunitĂ Essendo la comunitĂ un sistema complesso, all'interno del quale le molteplici interazioni tra gli utenti producono e etti non prevedibili che possono portare a fenomeni di disordine e caos, si puĂ˛ parlare di sistema auto-organizzante, ovvero di un sistema che tende a migliorare le sue capacitĂ nel corso del tempo organizzando meglio i suoi elementi per raggiungere l'obiettivo preposto. Questo processo di auto-organizzazione della comunitĂ Ă¨ ancora una volta favorito da una organizzazione di tipo modulare. Infatti la comunitĂ ha il compito non solo di sviluppare la sorgente ma anche, vista la scala degli oggetti che vengono realizzati, di sperimentare la validitĂ della sorgente attraverso la sua realizzazione. Se per l'open design, come si Ă¨ detto, la realizzazione Ă¨ una fase piuttosto semplice (grazie alla possibilitĂ di prototipare e produrre oggetti a basso costo), per l'Architettura Open Source ciĂ˛ non Ă¨ sempre possibile sia per problemi di tipo economico che per problemi di tipo pratico. Per ovviare al fatto che solo i promotori sono in grado di e ettuare le loro realizzazioni, molto spesso le iniziatiave di Architettura Open Source favoriscono la nascita e lo sviluppo di comunitĂ locali. Open Source Ecology favorisce questo tipo di approccio e difatti la realizzazione di macchinari, al momento molto consistente presso l'E-Farm, sta avvenendo anche in altri paesi.

In Italia la sezione italiana di Open Source Ecology ha costruito la

CEB press, la pressa per la realizzazione di blocchi in terra stabilizzati. Wikihouse promuove invece la nascita di nuovi Chapter (sezioni) su base locale, attraverso la sottoscrizione di un manifesto di intenti comune, il quale garantisce una certa autonomia a ciascuna sezione ma allo stesso tempo tende a favorire lo scambio tra le varie sezioni grazie all'uso di una piattaforma comune. L'approccio di Open Architecture Network Ă¨ ancora diverso: idealmente qualsiasi progettista singolo o gruppo di persone potrebbe cominciare a lavorare con il resto della comunitĂ su qualsiasi progetto a scelta, oppure svilupparne uno per conto proprio. Il fatto di favorire la nascita di sotto comunitĂ su base locale ha due principali vantaggi: il primo Ă¨ quello di favorire la realizzazione di piĂš elementi in diverse parti del mondo, e far cosĂŹ crescere il lavoro sulla sorgente; il secondo Ă¨ quello di veri care l'adattabilitĂ dell'iniziativa a contesti di erenti. Tenendo conto del fatto che realizzare prototipi Ă¨ piuttosto costoso (rispetto al prototipo di una sedia il prototipo di una struttura edilizia a scala reale risulterĂ sicuramente piĂš costoso) e che gli sforzi per la sua realizzazione sono in generale piĂš alti, la divisione della comunitĂ in sotto comunitĂ locali

148

CAPITOLO 5.

STRUMENTI OPERATIVI

può risultare decisiva per la continuazione del progetto. Riprendendo il paragone con l'open design proviamo a immaginare il rapporto con la comunità di un utente.

Quest'ultimo ha deciso di realizzare un oggetto adattandolo

alle sue necessità, un oggetto di piccole o medie dimensioni, per esempio una sedia. Lo sviluppo della sedia viene fatto a partire dalla sorgente messa a disposizione dall'iniziativa di riferimento: attraverso i software appropriati, la sedia potrà prendere la forma desiderata dall'utente. Con molta probabilità l'utente sperimenterà dubbi o di coltà tecniche che verranno prontamente superati grazie all'aiuto della comunità. Una volta trovata la soluzione, l'utente farà in modo di procedere alla sua realizzazione rivolgendosi a un laboratorio specializzato o realizzando da solo la sua sedia. Questa operazione sarà tendenzialmente economica e veloce, e non necessiterà di grossi capitali nè tantomeno di forza lavoro eccessiva. Utilizzando il suo tempo libero, i suoi risparmi e la sua forza sica il nostro utente vedrà realizzato il suo oggetto. Se invece l'utente volesse costruire una casa o anche solo di un padiglione temporaneo, di cilmente il processo sarebbe lo stesso. L'utente avrebbe bisogno di aiuto anche solo per montare la struttura della casa, l'ammontare totale di capitale necessario sarebbe decisamente più alto, il tempo richiesto molto di più e, in generale tutto il processo richiederebbe più energie. Con molta probabilità, l'utente chiederebbe la collaborazione di amici, colleghi o parenti, contribuendo a creare una sotto-comunità che lavora al progetto ma su base locale. Alcune iniziative, piuttosto che lasciare all'utente la responsabilità di cercare per proprio conto degli altri utenti disposti a condividere con lui oneri e onori del progetto, favoriscono direttamente la nascita di sottogruppi locali, lasciando la necessaria libertà di azione a nché ciascun gruppo proceda nello sviluppo della sorgente secondo le sue aspirazioni (rispettando ovviamente una carta di intenti comune).

Un approccio di tipo modulare alla gestione e all'organizzazione della comunità permette una più rapida ed e cace distribuzione della sorgente e uno sviluppo più ampio e interessante della sorgente stessa. 5.3

Il progetto della piattaforma Che cosa è possibile `progettare' di una comunità? Non è pensabile infatti pensare di poter progettare direttamente le relazioni e la complessità di una comunità (cioè le caratteristiche che la rendono tale). Le discipline che tradizionalmente si sono interessate alle comunità (architettura, urbanistica, web design) non si sono orientate a progettare le relazioni ma le caratteristiche che, realizzate, favoriscono e

5.3.

IL PROGETTO DELLA PIATTAFORMA

149

sostengono la nascita e lo sviluppo di relazioni. L'infrastruttura necessaria alle relazioni, la loro piattaforma. In questo senso, Ă¨ conveniente parlare di piattaforma come oggetto dell'intervento progettuale. Ă&#x2C6; possibile progettare e fornire quelle condizioni fondamentali che, condivise all'interno della rete sociale dei partecipanti, fungono da infrastruttura all'emergenza della comunitĂ e della sua attivitĂ caratteristica.

(Menichinelli 2008, p. 55)

La piattaforma Ă¨ il supporto attraverso il quale la comunitĂ opera sulla sorgente. Essa Ă¨ oggetto di progetto da parte dei promotori e la sua essenza caratterizza fortemente tutto il funzionamento dell'iniziativa. In questo ultimo paragrafo verranno a rontati gli aspetti legati alla sua de nizione e verranno analizzati gli strumenti comuni che ne permettono la costruzione.

5.3.1 Strumenti e pratiche La piattaforma Ă¨, in generale, il luogo virtuale all'interno del quale la comunitĂ si confronta e la sorgente viene distribuita. La piattaforma Ă¨ l'infrastruttura che permette sia la distribuzione della sorgente sia la formazione e l'incontro della comunitĂ . In quasi tutti i casi essa Ă¨ rappresentata da un sito web all'interno del quale, previa registrazione, Ă¨ possibile interagire con gli altri utenti e avere accesso alla sorgente. Ma la piattaforma non Ă¨ solo luogo ma anche regole, non Ă¨ solo infrastruttura ma anche organizzazione. Pensiamo all'Open Architecture Network. La piattaforma fornisce un repository a tutti i naviganti, un database di materiale liberamente accessibile. Agli utenti registrati OAN fornisce anche la possibilitĂ di inserire materiale e di interegire con altri utenti. Ma non solo, OAN o re delle modalitĂ , delle regole e dei campi di inserimento, insieme a delle possibili licenze per il rilascio del materiale. Non Ă¨ semplice infrastruttura, Ă¨ anche modalitĂ di uso della stessa. Tale infrastruttura Ă¨ in parte sica, reale, composta da atomi e materia, e in parte virtuale, informativa, composta da bit. La parte reale della piattaforma Ă¨ composta dai server che la ospitano (la memoria sica) e da tutti quegli strumenti che permettono un uso proli co della sorgente. La piattaforma Ă¨ composta sĂŹ tendenzialmente da un sito web, ma anche da tutti i computer che ad esso si connettono, dai macchinari che vengono utilizzati per l'attivitĂ della comunitĂ (per esempio le stampanti 3D per le iniziative di Open Design). Per quanto riguarda la parte virtuale la piattaforma Ă¨ composta perlopiĂš da informazioni che si presentano sotto diverse forme. La forma piĂš comune Ă¨ il sito web corredato da tutti gli strumenti canonici di comunicazione tra utenti (blog, forum, newsletter, social network). Oltre a ciĂ˛, vi Ă¨ il repository,

150

CAPITOLO 5.

STRUMENTI OPERATIVI

ovvero l'archivio all'interno del quale viene custodita la sorgente e tutte le sue modi che e implementazioni. In genere attraverso l'uso del sito web si accede al repository. La piattaforma perĂ˛ non Ă¨ soltanto composta da elementi che garantiscono la comunicazione tra gli utenti e accesso alla sorgente, ma Ă¨ formata anche e soprattutto da tutti quegli elementi che garantiscono un uso corretto e proli co della sorgente. Questi elementi sono principalmente tre: regole, standard e software, tutti elementi strettamente connessi tra di loro. Per regole si intende l'insieme dei metadati che stabiliscono le modalitĂ di utilizzo della sorgente, ovvero le modalitĂ attraverso le quali ogni utente Ă¨ in grado di e ettuare un lavoro sulla sorgente al ne di espanderla o di utilizzarla per i propri ni. Le regole comprendono sia le licenze di uso della sorgente, sia le istruzioni per un suo corretto uso, come ad esempio la spiegazione del funzionamento di un nodo strutturale (come per Wikihouse) o del funzionamento di una griglia di riferimento (Openstructures). Al ne di garantire un corretto utilizzo della sorgente in modo che essa possa essere trasmessa a tutti gli utenti e in seguito ridistribuita, le varie piattaforme ricorrono all'utilizzo di standard. Lo standard puĂ˛ riguardare l'utilizzo di certi tipi di le piuttosto che di altri (su OpenStructures vengono usati principalmente le .dxf, facilmente leggibili da macchine a controllo numerico) oppure aspetti dimensionali (la dimensione e lo spessore dei pannelli utilizzati da Wikihouse, la griglia dimensionale di OpenStructures), o ancora piĂš semplicemente ci sono standard di lingua (tutte le piattaforme sono in inglese nella convinzione che questo faciliti l'accessibilitĂ degli utenti). Tutti questi standard sono volti a facilitare il lavoro sulla sorgente, dal momento che in assenza di standard si potrebbe cadere nel caos e nel disordine. Infatti in assenza di regole chiare le modi che alla sorgente probabilmente non sarebbero piĂš compatibili tra di loro e si passerebbe da una soluzione adattabile (la sorgente) a tante soluzioni adattate ma non piĂš compatibili tra di loro. Per facilitare il rispetto delle regole e degli standard in alcuni casi viene fatto uso di software ad hoc (nel caso di Wikihouse il plugin, nel caso di OpenStructures la griglia in formato digitale) il quale, automatizzando alcuni processi, garantisce all'utente il rispetto delle regole e l'uso corretto degli standard favorendo la produttivitĂ e l'accessibilitĂ della sorgente.

La piattaforma Ă¨ l'insieme di strumenti digitali che permettono alla comunitĂ di distribuire, implementare e sviluppare la sorgente.

5.3.2 Oltre il repository Rispetto alla piattaforma di un software open source, che comprende un sito web di presentazione, un archivio digitale del codice sorgente, un archivio della documentazione e uno spazio di dibattito per gli utenti (sia esso forum

5.3.

IL PROGETTO DELLA PIATTAFORMA

151

o gruppo di discussione), la piattaforma di un progetto di Architettura Open Source presenta più sfaccettature e componenti. Si è già parlato degli strumenti di discussione e di confronto, oltre a questi di solito si trova un sito web comprendente vari elementi (blog, news, aggiornamenti, video, foto e altri elementi multimediali), una serie di istruzioni per l'uso e, in alcuni casi, una serie di software, siano essi da installare in locale o da utilizzare in remoto, che servono per facilitare l'accesso alla sorgente. Questo software può essere sviluppato da terzi e utilizzato allo scopo, oppure può essere sviluppato dalla stessa comunità, risultando essere oggetto di sviluppo in parallelo alla sorgente. In alcuni casi tutti i codici della piattaforma vengono distribuiti liberamente per diventare oggetto di sviluppo: la piattaforma diventa così oggetto di sviluppo al pari della sorgente, poiché il grado di interattività posto in essere dalla piattaforma garantisce o meno l'accessibilità della sorgente. Lo sviluppo del software suppletivo segue normalmente in maniera pedissequa il processo di sviluppo di un altro analogo software open source.

Rispetto a un progetto di open source software la piattaforma assume

dunque un'importanza strategica diventando tramite tra utente, comunità e sorgente e facilitando i reciproci scambi. Se si pensa al ` atwriter' di Friedman la piattaforma assume all'incirca quel tipo di ruolo. In aggiunta a tutto ciò che è stato detto si trova solitamente un repository di tutto quello che è stato prodotto dalla nascita dell'iniziativa. A fronte di progetti piuttosto sviluppati, è possibile trovare una piattaforma principale e diverse altre piattaforme satellite (di scala regionale) collegate alla principale e normalmente dipendenti da essa. Oltre agli strumenti digitali, la piattaforma comprende anche le regole che stabiliscono l'accesso alla sorgente e la sua gestione, il funzionamento della comunità, l'organizzazione di eventuali sottocomunità e licenze di uso di tutto il materiale che viene prodotto (in molti casi licenze Creative Commons).

La piattaforma è oggetto, al pari della sorgente, di progetto da parte dei promotori e della comunità.

5.3.3 Piattaforma e interazione La piattaforma deve servire non solo a ospitare il lavoro della comunità, ma deve essere studiata in modo da favorire l'attività degli utenti. Uno studio e un progetto approfondito della piattaforma possono garantire una maggiore apertura nei confronti di nuovi utenti e favorire la crescita della comunità coinvolgendo anche i meno esperti. Una piattaforma che permette di accedere facilmente alla sorgente, di eseguire modi che minime ma immediatamente condivisibili, di ottenere risultati seppur minimi ma in breve tempo favorisce l'avvicinamento alla sorgente di diversi utenti. Al contrario una piattaforma

152

CAPITOLO 5.

STRUMENTI OPERATIVI

ostica, di di cile navigazione senza regole esplicitate a dovere non favorisce a atto l'avvicinamento di nuovi utenti, anzi, contribuisce al loro rapido allontanamento. Si puĂ˛ fare riferimento ai casi studio per osservare vari modelli di piattaforma: per quanto riguarda OpenSimSim, ad esempio, la piattaforma si attiva unicamente in alcuni precisi momenti attraverso la formazione di workshop aperti a tutti della durata di tre giorni.

Ovviamente se l'utente

non partecipa in quei tre giorni non avrĂ la possibilitĂ di partecipare no a quando non vi sarĂ un altro appuntamento simile. In questo caso il livello di interazione tra piattaforma e utenti Ă¨ piuttosto basso. OpenStructures invece distribuisce la sua griglia di progettazione sotto forma di le .skp liberamente scaricabile. Questo puĂ˛ essere aperto sul proprio computer di ciascun utente e da lĂŹ in poi l'utente si relaziona con la sorgente attraverso il suo pc e il frutto del lavoro puĂ˛ essere successivamente caricato sul sito. Tutte queste operazioni dipendono dall'utente: dal tempo che egli dedica al suo lavoro e dalle sua capacitĂ di utilizzo del software scelto.

Per Wikihouse Ă¨ ancora

diverso: Ă¨ stato infatti sviluppato un plugin per Sketchup con varie funzionalitĂ . La prima Ă¨ la possibilitĂ di aprire direttamente, all'interno del software di modellazione, i le presenti sul server attraverso un menĂš di scelta che contiene un'immagine rappresentativa di ciascun modello e una descrizione dello stesso. CiĂ˛ permette all'utente di accedere ai diversi le che compongono la sorgente in maniera piuttosto facile e veloce senza dover usare il browser. Il plugin permette poi di ottenere i le di taglio giĂ pronti per l'uso (la cui preparazione richiederebbe normalmente molto tempo e una certa esperienza) e di caricare sul sito dell'iniziativa il proprio modello. Ciascun modello Ă¨ giĂ predisposto per essere modi cato, scomposto e ricomposto con relativa facilitĂ dagli utenti meno esperti.

Non vi Ă¨ un livello minimo di interazione da raggiungere ma piĂš alta sarĂ l'interattivitĂ della piattaforma piĂš accessibile e aperta risulterĂ la sorgente.

Capitolo 6 Applicazione pratica In architecture, the vertical integration of computer-based design and manufacturing is giving rise to new forms of digital artisanship, narrowing the albertian divide between conceivers and makers. Likewise, the digitally enhanced horizontal integration of actors and agencies in the design and production process is already chellenging the modern notion of the architect's full authotial 1 control and intellectual ownership of the end product. (Carpo 2011, p. 117)

Al ne di sperimentare il funzionamento degli strumenti pratici de niti nel capitolo precedente e di veri carne la correttezza, si è deciso di attivare un'iniziativa di Architettura Open Source presso il Politecnico di Torino, iniziativa cha ha preso il nome di BrickShell.

Come verrà meglio spiegato

in seguito, l'esperienza di BrickShell ha avuto luogo all'interno di un workshop opzionale proposto agli studenti delle lauree magistrali in Architettura. BrickShell non è stata l'unica sperimentazione realizzata, ma è la più completa e la più utile, dal momento che è stata l'occasione per applicare la quasi totalità degli strumenti pratici messi a punto durante il lavoro di ricerca. In seguito si riassumono brevemente alcune esperienze personali relative all'Architettura Open Source e alla gestione di piattaforme online.

Nel

giugno 2011, poco dopo aver iniziato questo lavoro di tesi, vi è stata la partecipazione all'iniziativa promossa da OpenSimSim focalizzata sull'emergenza

1 In architettura, l'integrazione verticale tra progettazione digitale e produzione sta dando adito a nuove forme di artigianato digitale, ricucendo la spaccatura albertiana tra ideatori e fabbricanti.

Allo stesso modo, l'integrazione orizzontale tra i diversi soggetti

coinvolti nel processo progettuale e costruttivo sta minando la nozione moderna di controllo autoriale da parte dell'architetto e di proprietà intellettuale del prodotto nale. [traduzione italiana a cura dell'autore].

153

154

CAPITOLO 6.

post-sisma nipponico.

APPLICAZIONE PRATICA

L'esperienza di OpenJapan, giĂ illustrata in prece-

denza, nonostante gli evidenti limiti organizzativi e strutturali, ha avuto il merito di suscitare questioni e dubbi da cui sono scaturite molte delle ri essioni scritte n qui.

Il secondo corpus di esperienze signi cative Ă¨ stato il

lavoro di creazione di piattaforme di sostegno alla didattica per due atelier di progettazione architettonica presso il Politecnico di Torino: l'atelier del secondo anno della laurea triennale intitolato Lo spazio dell'abitare, tenuto dai professori Pierr-Alain Croset ed Edoardo Piccoli, e gli atelier del primo anno della laurea magistrale in Architettura, Costruzione e CittĂ , in cui si Ă¨ lavorato sulla cittĂ di Kigali (nel 2012) e sulla cittĂ di Cusco (2013) tenuti dai professori Pierre-Alain Croset, Angelo Sampieri e Simonetta Pagliolico. In queste occasioni Ă¨ stata o erta la possibilitĂ di progettare e realizzare piatta-

forme di condivisione pensate appositamente come supporto alla didattica . Si Ă¨ quindi potuto assistere in prima persona alla formazione di comunitĂ di utenti focalizzate sull'architettura, e alle dinamiche che si innescano grazie a uno strumento collaborativo tra i vari partecipanti. Seppur non ancora focalizzate sull'Architettura Open Source cosĂŹ come Ă¨ stata de nita nei capitoli precedenti, le esperienze pregresse sono state comunque molto utili per comprendere appieno il signi cato della cosiddetta `rivoluzione digitale' e cominciare a ragionare sulle possibili implicazioni che questa potrebbe avere sulle relazioni tra formazione dell'architetto, metodologia progettuale ed evoluzione del processo edilizio.

6.1

BrickShell

Nel gennaio 2013 Ă¨ iniziata la piani cazione didattica del workshop opzionale

Morfogenesi Computazionale, tenuto dal professore Mario Sassone. Il corso si rivolgeva a tutti gli studenti delle lauree magistrali in architettura del Politecnico di Torino. Il workshop Ă¨ stato piani cato per il secondo semestre dell'anno accademico, da marzo a giugno, con un appuntamento settimanale di 7 ore. La proposta del professore Mario Sassone comprendeva la collaborazione dello scrivente e dei colleghi del DAPe

arch. Tomas Ignacio Mendez

Echenagucia, arch. Iasef MD Rian e arch. Shaghayegh Rajabzadeh. Data l'organizzazione dei workshop opzionali, era prevista l'iscrizione di un numero di studenti variabile dai 10 ai 40 al massimo. Il titolo del workshop, Mor-

2 Le

piattaforme

questione

sono

reperibili

//areeweb.polito.it/didattica/spazioabitare/ didattica/cuscostudio/.

ai e

seguenti indirizzi: http: http://areeweb.polito.it/

3 Il DAPe Ă¨ la Scuola di Dottorato in Architettura e Progettazione edilizia attiva presso

il DAD - Dipartimento di Architettura e Design del Politecnico di Torino.

6.1.

155

BRICKSHELL

fogenesi Computazionale, sottointendeva che l'argomento principale sarebbe stato lo studio particolareggiato di strumenti di calcolo digitale appositamente pensati per lo sviluppo e la de nizione di forme nello spazio. L'aspetto computazionale, cioè derivato dall'uso di calcolatori per la risoluzione di problemi e calcoli normalmente inaccessibili per i tempi e le modalità di calcolo umane, viene quindi utilizzato per scopi di morfogenesi, ovvero di ricerca di forme. La morfogenesi computazionale è dunque: un metodo di ricerca di forme tramite il supporto di algoritmi, lineari o genetici. Il software è così in grado di generare delle forme all'interno di certi limiti imposti, si prosegue poi alla veri ca del loro comportamento (strutturale, acustico, etc.)

a eventuali ottimizzazioni e modi che. (Pugnale 2007). Tali strumenti, nel caso dell'edizione 2013 del corso, avrebbero dovuti essere usati per la de nizione di una struttura di muratura portante di forma libera, essendo questo uno dei temi di ricerca scienti ca di alcuni dei promotori (il prof. ne e l'arch.

Rajabzadeh in particolare) (Figura 6.1).

Sasso-

Si è deciso che tale

Figura 6.1: La ricerca sulle volte in muratura di forma libera si inserisce in un più ampio contesto internazionale. Nell'immagine, i risultati del gruppo di ricerca presso l'ETH di

Zurgio guidato dal professor Block (fonte: http://block.arch.ethz.ch/brg/research/ project/free-form-catalan-thin-tile-vault).

prototipo avrebbe dovuto essere un piccolo padiglione di meditazione per il campus del Politecnico di Torino, al pari di altri padiglioni già esistenti in

altri contesti simili . Tale scelta è stata dettata in primo luogo dalla volontà

4 Si fa qui riferimento alla Rothko Chapel a Houston ad opera di Philip Johnson, Howard Barnstone, Eugene Aubry and Mark Rothko; la MIT Chapel di Eero Saarinen a Cambridge; il Meditation Centre all'UNESCO di Tadao Ando a Parigi; il centro di me-

156

CAPITOLO 6.

Figura 6.2:

APPLICAZIONE PRATICA

Uno dei riferimenti progettuali di BrickShell:

preghiera a Khartoum realizzatto da TAMassociati.

il centro di meditazione e

La luce zenitale opportunamente

ltrata è stato uno dei temi progettuali principali di BRickShell (fonte:

tamassociati.org/PAGES/PAD/PAD_PrayerPavilion.html#).

http://www.

di de nire una funzione precisa ma non complessa (al ne di evitare di progettare un padiglione unicamente a scopo dimostrativo), e in secodno luogo per coinvolgere l'istituzione ospitante nel processo realizzativo, proponendo un manufatto che sarebbe potuto risultare di pubblica utilità. Si è deciso di chiamare il padiglione BrickShell, al ne di evidenziare le sua caratteristiche principali: la forma di un guscio, propria delle volte (Shell), e il fatto di essere realizzato in muratura (Brick). Il workshop si è dato come obiettivo non solo quello di trasferire la conoscenza circa i più avanzati strumenti digitali a supporto della progettazione architettonica agli studenti coinvolti, ma anche di indagare, attraverso la costruzione di un prototipo, le possibilità di controllo del progetto in fase realizzativa consentite da tali strumenti.

ditazione presso il centro cardio-chirurgico Salm a Khartum in Sudan di TAMassociati (Figura 6.2); la cappella temporanea di St-Loup a Pompaples di Local Architecture.

6.1.

157

BRICKSHELL

6.1.1 Obiettivi, ipotesi iniziali e adozione dell'Open Source All'inizio del corso gli studenti erano sedici.

Essendo il workshop pensato

per le laureee magistrali, vi erano studenti provenienti da corsi di erenti, con conoscenze e capacitĂ diverse. Il workshop si era posto tre obiettivi ambiziosi: portare gli studenti a occuparsi di morfogenesi computazionale, progettare un edi cio in volte di muratura di forma libera e, in ne, svolgere un'esperienza di cantiere piuttosto intensa.

Il tutto in circa quattro mesi, con un

solo appuntamento settimanale. Considerando che gli studenti non avevano speci che conoscenze sul tema e si doveva arrivare a realizzare un unico prodotto nale, si Ă¨ pensato che sarebbe stato meglio instaurare un processo di tipo collaborativo in cui tutti gli studenti potevano partecipare cooperando, piuttosto che seguire un modello pedagogico di tipo concorrenziale, secondo il quale ogni studente (o gruppo di studenti) avrebbe dovuto sviluppare un progetto, e il progetto migliore sarebbe stato selezionato per essere poi realizzato. Infatti questo secondo tipo di approccio non sempre funziona, poichĂŠ nella successiva fase realizzativa, dopo la proclamazione di un vincitore, sono impegnati solo gli autori del progetto (a cui sta a cuore la corretta realizzazione) e non tutti gli altri partecipanti. Essendo la componente pratica uno degli obiettivi del corso, non sarebbe stato possibile limitarla a pochi partecipanti, ma era necessario trovare un modo per coinvolgere tutti gli studenti iscritti. Inoltre il carico di lavoro del workshop era piuttosto intenso e sarebbe risultato troppo oneroso in termini di tempo se ogni partecipante avesse dovuto lavorare in forma individuale. Si Ă¨ dunque pensato che un sistema aperto, basato sul modello open source, potesse essere utile sia per quanto riguarda l'aspetto didattico (facendo riferimento alla learning organization cui si faceva cenno nel primo capitolo), sia dal punto di vista progettuale (in un sistema in cui i partecipanti hanno poco tempo e poca esperienza Ă¨ meglio se gli forzi si uniscono invece che dividersi), sia dal punto di vista della costruzione (far a ezionare tutta la comunitĂ al progetto in modo che questo venga costruito collegialmente). BrickShell Ă¨ quindi diventato un progetto di Architettura Open Source.

5 Giulio Vianello, Emanuele Protti, Priscilla Thiesen Becsi, Gabriele Simonetta, Mariangela Rossino, Riccardo Pilleri, Silatchom Meguem Tadie, Santiago Jimenez, Simone Iennarella, Andrea Galli, Joline Folle, Fulvio Brunetti, Wilian Destefani, Tito Ceci De Sena, Carlos Henrique De Assis, Giovanni Bouvet.

158

CAPITOLO 6.

APPLICAZIONE PRATICA

6.1.2 Tema e campo di applicazione Il tema di questa particolare esperienza Ă¨ quello delle volte di forma libera in muratura.

Sul tema delle volte Ă¨ possibile trovare edi ci di vario tipo

e con funzioni diversi ma Ă¨ stato scelto di realizzare un edi cio di uso e utilitĂ pubblica all'interno del Politecnico di Torino. Il campo di applicazione principale Ă¨ la didattica, un campo di applicazione che non era stato ancora esplorato dai casi studio presi in esame, i quali, come abbiamo visto, si sono concentrati su altri obiettivi.

Tuttavia con essi viene condiviso l'aspetto

informale dell'iniziativa, poichĂ¨ la natura sperimentale del workshop ha fatto in modo che tutta l'esperienza non potesse essere inquadrata nella normale attivitĂ edilizia ma avesse uno status particolare e non normato, sperimentale per l'appunto.

6.1.3 De nizione della sorgente Open-endedness, variability, interactivity, and partecipation are the technological quintessence of the digital age.

They are

here to stay And soon designers will have to choose. They may design objects, and then be digital interactors. Or they may design objectiles, and then be digital authors. The latter choice is more 6 ardous by far, but its reward are greater. (Carpo 2011, p. 126) Il workshop Morfogenesi Computazionale si Ă¨ basato sulla de nizione di algoritmi. Questi possono essere descritti, secondo quanto a ermato da David Knuth, uno dei padri dell'informatica, come una sequenza ben de nita di regole che ci dicono come produrre o calcolare un'informazione, in base a un insieme di dati precedentemente assegnati, in un numero nito di passi . Per la compilazione di tali algoritmi viene utilizzato solitamente un linguaggio di programmazione e la sintassi che il linguaggio scelto prevede. Per poter scrivere un algortimo non per forza Ă¨ necessario conoscere un linguaggio di programmazione e la sua sintassi, poichĂ¨ alcuni programmi (e alcuni di questi sono programmi cad 2d/3d) hanno implementato degli strumenti di programmazione visuale. CiĂ˛ signi ca che invece che scrivere ogni singola funzione di un algoritmo attraverso un linguaggio di programmazione, Ă¨ possibile ottenere lo stesso risultato tramite la manipolazione gra ca degli elementi e non

6 L'apertura in nita, la variazione, l'interattivitĂ e la partecipazione sono la quintessenza tecnologica dell'etĂ digitale. Non sono un fenomeno passeggero. E presto i progettisti dovranno scegliere. Potranno disegnare oggetti, e in seguito interagirvi attraverso il digitale. O protranno disegnare degli objectiles, e diventare degli autori digitali. La seconda scelta Ă¨ piĂš di cile, ma la ricompensa Ă¨ maggiore. [traduzione italiana a cura dell'autore].

6.1.

BRICKSHELL

159

tramite sintassi scritta. Uno strumento di programmazione visuale consente di programmare con espressioni visuali, essendo basato sull'idea `boxes and arrows'

, dove le `boxes' (scatole contenti oggetti, parametri o funzioni) sono

collegate logicamente tra di loro attraverso le `arrows' (letteralmente frecce, ovvero i collegamenti logici tra le parti). La sorgente, essendo il workshop focalizzato sulla morfogenesi computazionale, Ă¨ costituita da un algoritmo (o un insieme di piĂš algoritmi).

CiĂ˛

signi ca che invece di avere un disegno di una forma o di un oggetto, o un modello tridimensionale, si hanno delle istruzioni e funzioni che portano alla de nizione di quella forma. L'insieme di queste istruzioni dĂ luogo a un modello parametrico, un modello la cui forma puĂ˛ essere variata agendo su opportuni parametri (parametri dimensionali, ambientali, strutturali, normativi o altro). Il modello parametrico diventa dunque la sorgente del progetto BrickShell. La natura di questa sorgente presenta due modalitĂ di interazione piuttosto diverse. La prima modalitĂ , pensata per utenti esperti, Ă¨ rivolta alla de nizione della sorgente. Attraverso l'uso del software appropriato Ă¨ possibile de nire la sorgente e, di conseguenza, la forma di BrickShell, agendo direttamente sul modello parametrico, scegliendo cioĂ¨ quali parametri includere, quali funzioni utilizzare e quali solo le relazioni logiche che intercorrono tra di loro.

Questo lavoro assomiglia molto al lavoro che viene fatto nor-

malmente sul software, dove le varie funzionalitĂ del software vengono via via implementate, migliorate, sempli cate, aggiunte o tolte a seconda delle necessitĂ . La seconda modalitĂ di interazione avviene quando si agisce sulla variazione dei parametri che de niscono alcune caratteristiche principali del modello. Agendo sui parametri, la sequenza logica dell'algoritmo non viene cambiata ma si modi ca il risultato nale. Si puĂ˛, ad esempio, variare la scala di un oggetto, variarne l'altezza e la larghezza, senza perĂ˛ riscrivere le regole che portano alla de nizione di quell'oggetto, ma agendo unicamente sulla variazione dei valori dei parametri. Le due modalitĂ sono ugualmente importanti poichĂŠ entrambe permettono di adeguare l'oggetto nale alle proprie necessitĂ , seppur necessitando di operazioni e conoscenze di base di erenti. La sorgente di BrickShell non comprende solo la sua de nizione formale, ma anche molte delle informazioni relative alla sua costruzione. Trattandosi di un edi cio di volte in muratura, la sorgente include anche la de nizione delle centine per la sua costruzione e, a livelli piĂš avanzati, potrebbe anche comprendere tutte le informazioni relative alla posizione e alla forma di ogni singolo mattone, qualora il singolo mattone dovesse essere oggetto di aggiu-

7 http://it.wikipedia.org/wiki/Linguaggio_di_programmazione_visuale

160

CAPITOLO 6.

APPLICAZIONE PRATICA

staggio (trattandosi di super cie di forma libera Ă¨ lecito aspettarsi che un pattern bidimensionale costante nelle dimensioni come quello della muratura non possa essere applicato uniformemente sulla super cie ma necessiti di qualche modi ca puntuale). Da tali considerazioni si evince che la sorgente sarĂ oggetto di continuo sviluppo e implementazione.

6.1.4 De nizione della comunitĂ Se pensate che nel vostro gruppo di lavoro ci sia qualcuno che ha un'idea migliore della vostra, perchĂŠ non accoglierla e svilupparla? Il risultato nale sarĂ diverso, e il confronto prezioso.

(Potter 2002, p. 172)

When you discuss your own work you have to ask yourself what you acquired from whom.

8 somewhere.

Because everything you nd comes from

(Hertzberger 1991, p. 5)

L'obiettivo principale del workshop Ă¨ naturalmente un obiettivo didattico. Essendo un'esperienza didattica esiste una comunitĂ prede nita formata da diversi utenti, i quali si possono suddividere in studenti (utenti sviluppatori) e docenti/tutor (utenti promotori). Un gruppo limitato di studenti Ă¨ quindi la comunitĂ di base. Questa limitazione puĂ˛ avere degli e etti negativi: la natura aperta dell'iniziativa non toglie la possibilitĂ che altri utenti si aggiungano alla comunitĂ , ma il tipo di esperienza proposto Ă¨ rivolto ad un gruppo molto speci co di persone.

Gli utenti possibili sono infatti degli architetti

o degli studenti di architettura, e, se studenti, tendenzialmente delle lauree magistrali vista la complessitĂ dei temi svolti, giĂ competenti per quanto riguarda la morfogenesi computazionale e, dato l'oggetto dell'iniziativa, tendenzialmente a liati al Politecnico di Torino. L'aspetto positivo di questa limitazione Ă¨ che una comunitĂ limitata di utenti Ă¨ facilmente monitorabile e le dinamiche che intercorrono tra i vari partecipanti possono essere registrate e analizzate agevolmente.

Questo secondo aspetto non Ă¨ da sottovalutare

poichĂŠ BrickShell non Ă¨ solo un workshop didattico, ma anche un esperimento scienti co sui seguenti aspetti: l'Architettura Open Source, la tecnica di costruzione di volte in muratura di forma libera, e in ne, l'utilizzo di avanzati strumenti di morfogenesi computazionale. La replicabilitĂ Ă¨ quindi alla base di questa esperienza, la quale vuole essere un modello per un possibile utilizzo di uso in futuro.

8 Quando analizzate un vostro lavoro dovete domandarvi che cosa avete acquisito e da chi. PoichĂŠ tutto ciĂ˛ che sviluppate arriva da qualche altra parte. [traduzione italiana a cura dell'autore].

6.1.

161

BRICKSHELL

6.1.5 De nizione della piattaforma With increasing globalization and specialization in the design and building industry, collaboration between partners in remote locations becomes crucial. Ideally, all of them could work on a building design at any place, simultaneously together (synchronously) or separately (asynchronously), while the latest state of the design would always be available in a shared database to all team members. They could collaborate on a shared object and no information would thus be lost in transfer of project data. But to be successful, this emerging type of collaboration often requires new design and communication methods

(Schmitt, Hirschberg, Kurmann, Kolarevic, Johnson & Donath 1999b) Per quanto riguarda la piattaforma ci si Ă¨ dovuti confrontare con alcune limitazioni che si sono presentate all'inizio dell'esperienza. La prima era dovuta alle risorse scarse di cui si disponeva per de nire una piattaforma ad hoc che potesse essere usata in modo pro cuo dalla comunitĂ . Una volta deciso di adottare l'Open Source come metodo di sviluppo, non si disponeva perĂ˛ del tempo necessario per poter progettare e realizzare un sito web che potesse ospitare un lavoro di tipo collaborativo senza che questa diventasse anch'essa una operazione di tipo sperimentale. Di conseguenza non era possibile avere una piattaforma stabile e di semplice utilizzo, con la possibile aggravante di caricare gli utenti di una frustrazione non necessaria (dovuta al funzionamento non uido della piattaforma), rischiando cosĂŹ il fallimento dell'iniziativa. Infatti in altre esperienze didattiche che hanno fatto uso di piattaforme di collaborazione disegnate ad hoc (gli atelier Lo spazio dell'abitare tenuti dal professori P.A. Croset ed E. Piccoli presso il Politecnico di Torino a partire dal 2011) ci si era scontrati con una certa di coltĂ iniziale di utilizzo da parte di utenti non esperti, di coltĂ che era stata superata col tempo ma in condizioni di utilizzo relativamente rilassate e in cui la piattaforma non era lo strumento principale di lavoro ma uno strumento di accompagnamento. Oltre alla mancanza di risorse per la sperimentazione, era da tenere in considerazione la poca familiaritĂ degli utenti con gli strumenti proposti, fa-

9 A seguito della crescente globalizzazione e specializzazione nel campo della progettazione e costruzione degli edi ci, la collaborazione tra colleghi in luoghi anche distanti tra loro diventa cruciale. Idealmente, tutti loro potrebbero lavorare sullo stesso progetto pur stando in posti di erenti, simultaneamente o in momenti diversi, in modo che l'ultima versione del progetto sia sempre disponibile in un database condiviso a tutti i membri del gruppo di progettazione. Possono collaborare su di un progetto condiviso senza che alcuna informazione venga persa durante i trasferimenti di dati. Ma per fare ciĂ˛ con successo, questo nuovo metodo di collaborazione richiede nuovi metodi di progettazione e di comunicazione. [traduzione italiana cura dell'autore].

162

CAPITOLO 6.

APPLICAZIONE PRATICA

miliaritĂ che doveva invece essere coltivata con un certo sforzo nei confronti dei software di progettazione parametrica. La de nizione di una piattaforma disegnata appositamente per BrickShell non Ă¨ stata dunque una prioritĂ , ma ciĂ˛ non ha impedito che si potessero comunque mettere a punto altri strumenti altrettanto validi per ottenere una piattaforma funzionante e performante. Si Ă¨ quindi scelto di suddividere la piattaforma in diversi servizi e, per ogni servizio, di utilizzare uno strumento giĂ esistente modi candolo secondo le proprie necessitĂ , tentando di utilizzare strumenti che fossero di grande di usione di modo da superare anche l'iniziale di denza degli utenti piĂš recalcitranti. Per il repository u ciale e il sito web principale si Ă¨ deciso di appoggiarsi a una piattaforma esistente di cui in precedenza si Ă¨ parlato lungamente: l'Open Architecture Network. Come giĂ segnalato, questa piattaforma risulta essere disponibile a ospitare progetti aperti di vario genere, che possono trovare un luogo dove avviare la propria attivitĂ senza particolari risorse iniziali. La pagina di BrickShell sull'Open Architecture Network diventa dunque il sito web principale e il repository dell'iniziativa

. La pagina Ă¨ visitabile da

parte di chiunque ma puĂ˛ essere modi cata solo dagli utenti registrati e il materiale Ă¨ liberamente scaricabile da chiunque.

Inoltre OAN permette di

utilizzare licenze Creative Commons per tutto ciĂ˛ che viene condiviso. Per quanto riguarda invece la comunicazione e il confronto tra gli utenti Ă¨ stato scelto di utilizzare un network sociale di utilizzo di uso di modo che non ci fossero problemi o di coltĂ di utilizzo, come Facebook

, nella con-

vinzione che la di usione presso gli studenti dell'ateneo (e non solo) potesse favorire l'accesso da parte di nuovi utenti. Facebook dĂ la possibilitĂ a chiunque di realizzare una pagina dedicata a un singolo argomento, e di fare in modo che sia possibile condividere vari materiali in maniera piuttosto facile e

diretta. Un ulteriore strumento utilizzato Ă¨ stato Dropbox personale di archiviazione e condivisione di dati.

, uno strumento

Il software in questione,

installato sul computer di ciascun utente, permette a chi lo utilizza di poter conservare dei dati sui server messi appositamente a disposizione e di potervi accedere da diversi computer o, addirittura, di poter condividere con altri utilizzatori intere cartelle di le. DĂ inoltre la possibilitĂ di ottenere un link per ciascun le caricato, link che puĂ˛ essere facilmente condiviso e che risulta essere sempre attivo. CiĂ˛ permette agli utenti di poter condividere dei le di lavoro attraverso la piattaforma Facebook in totale sicurezza e relativa

10 http://openarchitecturenetwork.org/projects/BrickShell

11 https://it-it.facebook.com/pages/BrickShell/155528374601155 12 https://www.dropbox.com/

6.1.

163

BRICKSHELL

facilitĂ unicamente postando il link del le interessato. utilizzato anche Google Drive

In ultimo Ă¨ stato

, un servizio gratuito messo a disposizione

da Google che permette a piĂš utenti di lavorare su documenti condivisi come ad esempio le di testo o tabelle di calcolo. Inoltre vi sono gli strumenti che normalmente vengono utilizzati per operare direttamente sulla sorgente. Questi sono principalmente due: Rhinoce-

ros

e Grasshopper

. Il primo Ă¨ un software di modellazione tridimensionale

tramite NURBS, ovvero Non Uniform Rational B-Spline, un metodo algoritmico per la costruzione di curve e superi ci free-form, molto utile se non indispensabile in questo caso. Il secondo Ă¨ un plugin del primo, ovvero un software che si attiva all'interno del piĂš complesso Rhinoceros, e che o re un sistema di programmazione visuale.

Permette cioĂ¨ di utilizzare le funzioni

derivanti dai comandi di Rhinoceros come oggetti visuali, e di collegarli logicamente a parametri e oggetti disegnati. Se il primo puĂ˛ essere scaricato in versione di prova, il secondo puĂ˛ essere scaricato liberamente. La versione di prova di Rhinoceros permette unicamente 25 salvataggi, dopodichĂŠ continua a funzionare ma non permette di salvare. Dal momento che perĂ˛ i le vengono creati unicamente con Grasshopper, la limitazione di Rhinoceros non costituisce un problema.

6.1.6 Svolgimento Preparazione The preparation of a collaborative project naturally must be 16 a collaborative e ort in itself. (Schmitt, Hirschberg, Kurmann, Kolarevic, Johnson & Donath 1999a) Il primo mese del workshop Ă¨ stato dedicato a diverse attivitĂ propedeutiche. La maggior parte degli sforzi dei partecipanti si sono concentrati sull'apprendimento dei metodi di progettazione parametrica. Parallelamente a questo tipo di approfondimento vi Ă¨ stato lo studio delle tecniche di costruzione delle volte e della scienza delle costruzioni. Oltre a queste componenti c'Ă¨ stata anche l'introduzione delle varie componenti della piattaforma, nella convinzione che esattamente come si puĂ˛ imparare a realizzare e gestire un

13 http://www.google.com/intl/it/drive/about.html 14 http://www.rhino3d.com/

15 http://www.grasshopper3d.com/

16 La piani cazione di un progetto collaborativo deve naturalmente essere anch'essa una operazione collaborativa. [traduzione italiana cura dell'autore].

164

CAPITOLO 6.

APPLICAZIONE PRATICA

modello parametrico si possa imparare a collaborare e cacemente con altre persone. Sono state messe a punto alcune piccole esercitazioni che potessero permettere agli utenti di utilizzare la piattaforma e di collaborare come in una comunitĂ avviata. Questi esercizi sono stati piani cati seguendo il modello di quanto era stato fatto giĂ nel 24 Hour Design Cycle (Schmitt et al. 1999a) dai professori Schmitt e Hirschberg dell'ETH di Zurigo. Le esperienze svolte presso l'ateneo svizzero prevedevano infatti risoluzioni cooperative a problematiche progettuali attraverso un uso collaborativo della rete (siamo nel 1999, ancora lontani dal web 2.0).

Il lavoro del 24 Hour Design Cycle si basava

sul modello della sta etta: prevedeva il coinvolgimento di diverse scuole di architettura su scala mondiale (Zurigo, Shanghai e Seattle) e l'obiettivo era quello di far lavorare gruppi di studenti di diversa provenienza come in una sta etta a tempo, con turni equivalenti e con un scambio continuo del progetto, il quale procedeva nella sua de nizione insieme al lavoro svolto dai vari gruppi (Figura 6.3). Questo modello di collaborazione, legato alla successio-

Figura 6.3: L'esperienza del 24 hour Design Cycle viene rappresentata in questo schema: i gruppi d iprogettazione si sono scambiati i le di lavoro durante 24 ore tra le tre sedi coinvolte. L'immagine Ă¨ tratta da Schmitt et al. (1999b).

6.1.

165

BRICKSHELL

ne temporale e logica dei turni di lavoro, pemette un avanzamento costante e un riconoscimento necessario del lavoro del proprio predecessore. Risulta molto e cace per esperienze che devono essere svolte in tempi ristretti (ad esempio OpenSimSIm con l'esperienza OpenJapan ha adottato lo stesso sistema) e costringe ogni utente a confrontarsi con il lavoro e con le posizioni dei propri colleghi. In questo senso, la prima esercitazione ha previsto la compilazione di un racconto collaborativo. Dato l'inizio e la ne del racconto e un elenco di turni di scrittura, ogni utente Ă¨ stato chiamato, seguendo l'ordine prestabilito, a scrivere una parte intermedia del racconto seguendo ciĂ˛ che era stato scritto precedentemente dal proprio compagno. L'ultimo utente si sarebbe dovuto poi collegare alla ne della narrazione giĂ presente nel documento. E ettuata lungo la prima settimana di lavoro, questa esercitazione ha previsto l'uso di Google Drive per la scrittura condivisa e di Facebook per la condivisone di quanto scritto.

L'esperimento ha avuto successo:

tutti gli utenti coin-

volti hanno partecipato e ognuno ha contribuito a sviluppare una parte del racconto. Il secondo esercizio prevedeva lo sviluppo di un semplice algoritmo attraverso Grasshopper.

Organizzato nella stessa maniera dell'esercitazione

precedente, ogni utente ha utilizzato Rhinocerso e Grasshopper e condiviso il lavoro con gli altri utenti via Facebook utilizzando Dropbox.

In questa

esercitazione gli utenti dovevano contribuire a comporre una de nizione di algoritmo attraverso l'uso di Grasshopper e per fare ciĂ˛, ogni utente poteva aggiungere due elementi, sostituire un elemento o eliminare due elementi giĂ presenti nel le. Dopo queste operazioni il le doveva essere passato all'utente successivo, il quale poteva a sua volta e ettuare le operazioni che aveva a disposizione e cosĂŹ via. Si Ă¨ partiti da un le molto semplice con qualche parametro per arrivare a una de nizione piĂš complessa e a un prodotto nale pressochĂŠ completo. Anche questo esercizio ha avuto successo, nel senso che l'algoritmo Ă¨ stato sviluppato, l'elenco Ă¨ stato seguito e qualche utente ha continuato a sviluppare l'algoritmo anche dopo la ne dell'esercitazioneo. Il terzo esercizio si Ă¨ focalizzato sull'utilizzo di Grasshopper: data una de nizione di algoritmo piuttosto complicata, ogni utente era chiamato a effettuare operazioni di sempli cazioni. Per fare ciĂ˛ si sono seguiti gli stessi principi che governavano l'esercitazione precedente e anche gli stessi strumenti.

Sviluppo collettivo della sorgente

Terminata la fase di preparazione gli

utenti erano ormai in grado di gestire un modello parametrico, di utilizzare la piattaforma messa a loro disposizione, e si erano abituati a lavorare in modo

166

CAPITOLO 6.

APPLICAZIONE PRATICA

Figura 6.4: La versione 0.00 di BrickShell: il diagramma.

collaborativo. Si Ă¨ quindi iniziato il lavoro sulla sorgente. Tale lavoro, svolto in maniera collaborativa, ha portato alla de nizione della prima e ettiva sorgente progettuale da cui Ă¨ stato sviluppato il modello parametrico. Come si Ă¨ detto in precedenza l'oggetto progettuale Ă¨ stato un padiglione di meditazione per il campus del Politecnico di Torino. Sulla scorta di esempi giĂ citati in precedenza, la comunitĂ di BrickShell Ă¨ stata chiamata a progettare e realizzare un centro di meditazione per l'Ateneo torinese. In un periodo di circa due settimane si Ă¨ quindi ragionato, e attraverso la piattaforma online e attraverso gli incontri settimanali sui caratteri che questa nuova architettura avrebbe dovuto includere, sia partendo da riferimenti di tipo architettonici, che da riferimenti diversi di tipo artistico, costruttivo e naturale. Il risultato di questa prima fase di lavoro Ă¨ stato sintetizzato in un diagramma contenente tutti gli elementi condivisi a cui la comunitĂ avrebbe potuto attingere per il suo lavoro futuro (Figura 6.4). Il diagramma presenta quattro principali ambiti di indagine: idee generali, dispositivi spaziali, gure geometriche e tecniche costruttive. A queste quattro componenti vengono collegati alcuni dei riferimenti principali presi in esame.

Le idee generali comprendono tutti quei caratteri propri di un

centro di meditazione che la comunitĂ ha deciso di implementare: si tratta

6.1.

167

BRICKSHELL

perlopiĂš di sensazioni che il risultato nale dovrebbe suscitare nel visitatore o di modalitĂ di fruizione e di funzionamento dell'edi cio.

All'interno dei

dispositivi spaziali sono comprese alcune soluzioni che, se utilizzate, garantirebbero alcuni degli e etti auspicati dalle idde generali. Nel caso delle gure si tratta di con gurazioni geometriche esistenti che possono essere prese da esempio. Nella voce `tecniche costruttive' sono annoverate alcune delle possibili disposizioni dei mattoni che possono essere utilizzate e cacemente per realizzare la volta in forma libera di muratura.

Il diagramma Ă¨ diventato

la prima sorgente progettuale da cui la comunitĂ Ă¨ partita per costruire il modello parametrico. Se normalmente la sorgente viene de nita a priori dai promotori dell'iniziativa, in BrickShell si Ă¨ preferito procedere alla de nizione di una sorgente condivisa, considerando che l'utilitĂ pubblica e la particolare funzione dell'oggetto da costruire necessitassero di un processo di de nizione collaborativo. L'unico elemento de nito a priori dai promotori Ă¨ stata la componente costruttiva, ovvero il fatto che l'edi cio nale dovesse necessariamente essere realizzato in volte di forma libera in muratura.

Metodo di sviluppo collaborativo

Il metodo `a sta etta' di Schmitt e

Hirschberg, che Ă¨ si Ă¨ dimostrato molto e cace in una fase iniziale, non Ă¨ stato piĂš adottato in seguito, cioĂ¨ nel momento in cui si Ă¨ iniziato a sviluppare la sorgente in modo aperto.Tale scelta Ă¨ motivata dalle seguenti considerazioni. La prima Ă¨ che la de nizione di turni non permette il facile inserimento di nuovi utenti. In un sistema completamente aperto un utente puĂ˛ prendere liberamente la sorgente, apportare le sue modi che secondo il suo interesse e la sue necessitĂ , presentare i risultati alla comunitĂ e di lĂŹ in poi si attua quel fenomeno organizzativo basato sulla reputazione di cui si Ă¨ parlato abbondantemente in precedenza. Invece in un sistema troppo rigido di turni ciĂ˛ non potrebbe avvenire, sia perchĂŠ il giudizio sull'operato del nuovo utente sarĂ emesso unicamente dal suo successore nella lista prede nita, sia perchĂŠ non vi Ă¨ un sistema per de nire quale utente puĂ˛ essere inserito nella lista e quale no. Quindi un sistema libero sembra piĂš e cace, proprio perchĂŠ che un sistema di turni limita molto l'attivitĂ della comunitĂ . Inoltre se Ă¨ vero che un un sistema a turni puĂ˛ funzionare bene in comunitĂ molto ridotte e giĂ prede nite (come puĂ˛ essere la comunitĂ di un gruppo di studenti di uno speci co corso), va aggiunto perĂ˛ che il fattore temporale, che stabilisce l'e cacia di un sistema di turni in un tempo ben de nito e comunque ridotto, limiterebbe il workshop a qualche giorno. In un sistema piĂš essibile, che si protrae magari per qualche mese o anno, non Ă¨ detto che il sistema a turni funzioni altrettanto bene. Bisogna infatti considerare anche altri elementi:

168

CAPITOLO 6.

APPLICAZIONE PRATICA

l'Open Source per come lo conosciamo Ă¨ un sistema di lavoro volontario, non remunerato in forma economica diretta (attraverso una transazione monetaria) ma attraverso altri canali, come ad esempio l'esperienza acquisita, la risoluzione a basso costo di una istanza personale, il semplice hobby creativo. Come tale di cilmente puĂ˛ essere inquadrato in un sistema di lavoro organizzato per turni obbligatori. Come a ermava Stallman ( free as in freedom ), la libertĂ sta alla base del sistema, il che permette a ogni utente di intervenire come e quando gli Ă¨ piĂš congeniale, favorendo un utilizzo piĂš e cace della `risorsa' utente secondo i tempi e i modi de niti da ogni singolo partecipante. Questo sistema, che a prima vista puĂ˛ sembrare confusionale, ha in realtĂ dimostrato la sua e cacia in quasi tutte le iniziative legate all'Open Source. Ă&#x2C6; vero che l'assenza di turni puĂ˛ generare due o piĂš versioni `parallele' contrastanti, poichĂŠ Ă¨ possibile che due utenti lavorino contemporaneamente sulla sorgente ma sviluppino soluzioni diverse. Tuttavia ciĂ˛ non risulta essere un problema dal momento che in maniera autonoma una delle versioni, probabilmente la piĂš valida o quella che la comunitĂ ritiene essere la piĂš valida, verrĂ ulteriormente sviluppata mentre le altre verranno abbandonate. Si Ă¨ deciso dunque di lasciare gli utenti liberi di gestire lo sviluppo della sorgente in maniera assolutamente autonoma, adottando come unico sistema di organizzazione quello del versioning.

Versioning

Il versioning Ă¨ il metodo attraverso il quale le varie versioni

progressive di un software vengono nominate.

Solitamente si tratta di un

sistema di numerazione che permette di identi care alcune `major release' (versioni complete del software che comprendono una serie di funzionalitĂ ) e le relative `minor release' (versioni successive a una major release il cui scopo Ă¨ quello di a nare il funzionamento della stessa e risolverne i malfunzionamenti).

Il versioning viene realizzato attraverso una numerazione

progressiva, a partire dallo zero.

Ogni versione Ă¨ indicata attraverso l'uti-

lizzo di due numeri separati da un punto. Il primo numero indica la major release, il secondo la minor release.

La prima versione si chiamerĂ quindi

versione 0.0, le sue minor release 0.1, 0.2, 0.3 e cosĂŹ via, no ad arrivare alla seconda versione, la 1.0. Al versioning Ă¨ dovuta anche la denominazione web 2.0, ovvero una versione del web piĂš avanzata rispetto quella precedente. Lo stesso sistema Ă¨ stato usato anche per la comunitĂ di BrickShell. A una major release principale (la cui forma e i cui contenuti sono stati de niti negli incontri settimanali in maniera collegiale) sono corrisposte diverse minor releases durante il corso della settimane. Tali minor releases sono state prodotte da ciascun utente secondo le sue particolari capacitĂ . La numerazione ha aiutato il resto della comunitĂ a orientarsi all'interno del materiale

6.1.

169

BRICKSHELL

Figura 6.5: L'evoluzione della versione 1.00.

prodotto. Ciascuna major release è stata resa disponibile sulla piattaforma OAN ogni settimana, per un totale di 8 settimane. Ciò ha permesso di stabilire uno stato dell'arte settimanale su cui è stato possibile lavorare in seguito. Durante la settimana ogni utente ha lavorato liberamente e portato avanti il lavoro in piena autonomia; non appena raggiunto qualche progresso signi cativo si è condiviso con il resto della comunità l'esito del lavoro. La comunità poteva osservare il lavoro svolto e se un altro utente valutava che la sorgente si stava sviluppando in maniera positiva, poteva continuare il lavoro iniziato in precedenza. In caso di più versioni `parallele' è stata la versione reputata migliore ad essere automaticamente sviluppata, mentre le altre sono rimaste in uno stato di `work in progress' e abbandonate nel momento in cui una nuova versione u ciale è stata rilasciata. Data la natura della sorgente è anche possibile che le modi che apportate non stravolgano la forma nale prodotta dallo script, ma che siano modi che migliorative sullo script stesso per aumentare l'e cacia, la velocità e l'accessibilità, ovvero facilitarne l'uso da parte di altri. Lo script di Grasshopper tende infatti a essere territorio di sperimentazione continua e non sempre le soluzioni trovate, seppur riuscendo a raggiungere l'obiettivo preposto, sono le migliori dal punto di vista della programmazione. Si tratta cioè di script ridondanti e complessi che possono essere in seguito sempli cati. Questo lavoro di sempli cazione può essere oggetto di una nuova versione da parte di un utente, analogamente a quanto avviene nello sviluppo del software, dove ad ogni major release corrispondono svariate minor releases il cui scopo è quello di riparare i bachi esistenti.

Analisi dello sviluppo

Lo sviluppo della sorgente è avvenuto seguendo

rilasci settimanali e lavorando sulla sorgente il resto del tempo. Dopo ciascun rilascio, sono stati identi cati gli obiettivi del rilascio successivo di modo che in capo a un paio di mesi si potesse ottenre un prodotto nito pronto per essere costruito.

170

CAPITOLO 6.

APPLICAZIONE PRATICA

Le versioni dalla 1.0 alla 4.0 hanno visto la genesi della forma e la costruzione di un modello parametrico che fosse in grado di de nire e cacemente la forma desiderata (Figura 6.5). Questa fase comprende contributi di diverso tipo: da un lato un lavoro sulle varie parti e funzioni del modello, dall'altro un lavoro sui parametri e sulla loro variazione. Attraverso la versione 5.0 e 6.0 è stata de nita la forma nale di BrickShell con un'attenzione alle problematiche costruttive: in queste versioni sono state introdotte le centine per la costruzione e gli strumenti di controllo strutturale.

La versione 7.0 è il

risultato del lavoro sulla componente strutturale e sul controllo della curvatura in ogni punto della super cie. In particolare il controllo della curvatura (e di conseguenza l'analisi strutturale) è stato condotto a modello ultimato, agendo unicamente sui parametri. Attraverso la variazione dei parametri si è infatti riusciti a ottenere valori puntuali di curvatura accettabili su tutta la super cie. La versione 8.0 ha visto ultimato il lavoro sulle centine rendendo disponibili i pro li di taglio per la costruzione delle stesse (Figura 6.6). Nel

Figura 6.6:

La versione 8.00 della sorgente di BrickShell:

l'algoritmo realizzato con

Grasshopper. A partire da questa versione sono state realizzate le centine in cartone.

complesso sono state rilasciate 8 versioni (più la versione 0.00, il diagramma) del modello parametrico su un totale di 8 settimane. La comunità ha partecipato attivamente a tutte le versioni. In totale sono state sviluppate circa quaranta versioni intermedie distribuite tra le 8 settimane. Solo nelle prime settimane si è veri cata la presenza di versioni `parallele', ma nonostante questo il processo di sviluppo non si è fermato: la comunità ha continuato scegliendo di sviluppare sempre una delle proposte piuttosto che altre. La maggior parte delle versioni intermedie sono state sviluppate nelle prime settimane poiché la mole di lavoro era decisamente più alta.

Nelle settimane

successive il lavoro sui parametri e sulle centine ha permesso di avanzare con meno versioni intermedie.

Su un gruppo totale di 16 persone hanno lavo-

rato attivamente sulla sorgente (proponendo cioè versioni intermedie) circa 10 utenti coinvolti, mentre il resto del gruppo ha sviluppato tutti i materiali corredati, principalmente materiali esplicativi e gra ci.

6.1.

BRICKSHELL

Dal bit all'atomo

171

Per quanto riguarda la costruzione, ovvero il passaggio

da informazione digitale a materia sica, si Ă¨ proceduto all'organizzazione di un cantiere di tipo sostanzialmente tradizionale. Trattandosi di volte di forma libera, cioĂ¨ di geometrie di cilmente de nibili attraverso strumenti tradizionali, si Ă¨ dovuto procedere alla costruzione di adeguate centine in grado di fungere da punti di appoggio e guida per la corretta posa dei mattoni. Attraverso la costruzione delle centine si Ă¨ riusciti a trasferire la complessa informazione digitale riguardante la forma dell'edi cio in supporto provvisionale per la costruzione, evitando di compiere errori di posa e riuscendo a rimanere all'interno delle tolleranze imposte dalla natura stessa dell'edi cio. L'intera centina Ă¨ stata pensata come un calco a scala reale della forma desiderata, realizzata attraverso l'utilizzo di fogli di cartone ondulato rigido. Nel modello digitale l'intero volume coperto dall'edi cio Ă¨ stato sezionato da serie di piani verticali nelle due direzioni principali: la distanza tra i piani Ă¨ stata ssata a 20 cm. Ogni piano di sezione Ă¨ stato poi sagomato secondo l'andamento della volta sezionata: l'incastro dei vari piani sagomati tra di loro ricostruisce la sagoma dell'intero edi cio. Per facilitarne la costruzione, le sagome sono state realizzate in cartone ondulato e l'intera centina Ă¨ stata suddivisa in 20 moduli di base quadrata che, accostati gli uni agli altri, formano la sagoma completa. La distanza tra le sagome non Ă¨ stata casuale: bisogna considerare infatti che, essendo il mattone lungo 30 cm e venendo posato non per corsi orizzontali al terreno ma a spina di pesce, due piani distanti tra loro 20 cm o rono al mattone uno o due punti di appoggio, facilitando la posa in opera dello stesso (Figura 6.7). Per disegnare sui cartoni le sagome corrette di ciascun modulo si Ă¨ inizialmente pensato di procedere utilizzando una taglierina a controllo numerico. Il modello parametrico forniva le sagome corrette di ciascun modulo, si trattava dunque di trasferire l'informazione dal computer alla macchina e si sarebbero ottenute tutte le sagome pronte per l'assemblaggio. Tuttavia data la mancanza di risorse economiche (il macchinario non era presente presso l'istituzione ospitante e ci si sarebbe dovuti rivolgere a un laboratorio esterno) si Ă¨ deciso di procedere con gli strumenti disponibili. Presso il laboratorio LATEC del Politecnico di Torino, diretto dall'arch. Angela Lacirignola, Ă¨ stato installato un proiettore attraverso cui sono state proiettate tutte le sagome. L'immagine proiettata, convenientemente collimata e scalata (l'utilizzo di una griglia di riferimento disegnata sul piano su cui veniva proiettata l'immagine della sagoma, e di una griglia di riferimento propria del le proiettato, e la conseguente operazione di collimazione tra le due griglie hanno permesso di ottenere immagini proiettate a scala reale) Ă¨ stata riportata manualmente sui cartoni ondulati e poi ritagliata (Figura 6.8). Ogni pezzo Ă¨ stato etichettato e si Ă¨ poi proceduto con l'assemblaggio dei moduli. La muratura Ă¨ stata realizzata da tutti

172

CAPITOLO 6.

APPLICAZIONE PRATICA

Figura 6.7: Uno schema esplicativo del metodo di de nizione delle centine.

i paretecipanti nelle settimane successive la realizzazione delle centine.

costruzione Ă¨ stato un momento in cui Ă¨ stato possibile ampliare la comunitĂ iniziale poichĂ¨ l'attivitĂ di tipo ludico/costruttivo ha favorito la partecipazione di altri utenti che inizialmente non facevano parte del gruppo iniziale (Figura 6.9).

Dopo la costruzione

Terminata la costruzione si sono veri cati ancora al-

cuni fenomeni interessanti, come ad esempio quello della auto-organizzazione all'interno della comunitĂ .

Se per tutta la fase di sviluppo e realizzazio-

ne i promotori hanno partecipato attivamente all'attivitĂ , svolgendo anche funzioni di coordinamento e gestione della comunitĂ , a cantiere ultimato, immediatamente dopo la rimozione delle centine, i promotori, per motivi legati alla loro attivitĂ lavorativa, hanno dovuto smettere o quantomeno diminuire la loro presenza all'interno della discussione. Tuttavia ciĂ˛ non ha signi cato la ne dell'esperienza: il resto della comunitĂ si Ă¨ infatti auto-organizzata per e ettuare tutte le ri niture necessarie sulla volta e per concludere il cantiere. Attraverso l'uso degli strumenti utilizzati in precedenza (principalmente il network sociale) sono stati organizzati degli ulteriori momenti di lavoro che hanno permesso di ri nire tutti i giunti della muratura nell'intradosso della volta (che si presentavano ancora grezzi) e di ripulire e mettere in si-

6.2.

UTILITÀ DELLA SPERIMENTAZIONE

173

Figura 6.8: Il passaggio da bit ad atomo presso il laboratorio LATEC: l'immagine proiettata a scala reale viene trasferita manualmente sui supporti di cartoni. Verrà successivamente ritagliata e opportunamente montata.

curezza l'area di cantiere (Figura 6.10). Inoltre la comunità ha continuato la produzione di materiale esplicativo (è stato prodotto un video illustrativo dell'intero processo) e organizzato un momento di inaugurazione in cui è stata invitata tutta la comunità studentesca del Politecnico (Figura 6.11). Oltre a ciò si è cercato di continuare il lavoro sul modello parametrico, attraverso lo sviluppo di alcuni sistemi di controllo di ogni singolo mattone sull'intera super cie di BrickShell.

6.2

Utilità della sperimentazione

6.2.1 BrickShell: Architettura Open Source Riprendendo alcune delle de nizioni presentate nel capitolo precedente si può meglio comprendere perchè BrickShell può essere considerata un'esperienza di Architettura Open Source. La prima de nizione, ancora molto generale,

174

CAPITOLO 6.

APPLICAZIONE PRATICA

Figura 6.9: Le fasi di cantiere di BrikShell. Vengono posati mattoni seguendo la forma delle centine sottostanti in cartone.

conteneva le condizioni basilari per le quali Ă¨ possibile parlare o meno di Architettura Open Source:

si parla di Architettura Open Source quando una iniziativa progettuale cerca di adottare il modello Open Source all'interno del suo processo di sviluppo e, per fare ciĂ˛, vengono messe in atto adeguate azioni per implementarne la sorgente progettuale e, di conseguenza, creare la comunitĂ che sviluppa tale sorgente e la piattaforma attraverso la quale viene distribuita. Questa condizione Ă¨ stata soddisfatta: BrickShell infatti ha attinto a piene mani dalle esperienze di sviluppo open source del software e ha avuto come obiettivi principali quelli di sviluppare una sorgente progettuale adeguata e di costruire una comunitĂ che la sviluppasse attraverso l'uso di una piattaforma dedicata. A questo punto Ă¨ forse necessario ri ettere circa il motivo per cui BrickShell Ă¨ diventata un'esperienza di Architettura Open Source e non ha seguito il normale decorso di un workshop tradizionale. Alla base del corso vi era la necessitĂ di a rontare molte tematiche in relativamente poco tempo, e di

6.2.

UTILITĂ&#x20AC; DELLA SPERIMENTAZIONE

175

Figura 6.10: Brickshell: il padiglione di meditazione del Politecnico di Torino ultimato, poco prima di essere inaugurato.

ottenere un risultato che potesse essere costruito, ovvero un risultato completo di tutte quelle ri essioni che portano un progetto dal foglio da disegno al cantiere. Di cilmente si poteva pensare che gli sforzi di singoli studenti (o gruppi di studenti) potessero riuscire a raggiungere un tale obiettivo. PerciĂ˛ si Ă¨ pensato che l'unione degli sforzi in un unico progetto potesse risolvere in parte il problema, riuscendo a portare a termine l'iniziativa e a garantire il completamento dell'edi cio.

L'open source si sposava in pieno

con l'intenzione di gestire un progetto architettonico sviluppato in maniera collaborativa.

L'architettura Open Source non Ă¨ quindi un ne da perseguire, ma un potente strumento in grado di dare la possibilitĂ a chiunque di sviluppare progetti di architettura e di riplasmare il processo edilizio secondo le proprie necessitĂ . Si Ă¨ inoltre ragionato anche sulla e ettiva possibilitĂ di realizzazione del prodotto nale. Per fare ciĂ˛ si Ă¨ coinvolta da subito l'istituzione ospitante, o rendo un edi cio di utilitĂ pubblica e chiedendo in cambio un pezzo di terreno e le necessarie autorizzazioni per procedere alla realizzazione, senza

176

CAPITOLO 6.

APPLICAZIONE PRATICA

Figura 6.11: La rappresentazione nale del padiglione di meditazione BrickShell.

che vi fosse ancora un progetto de nitivo ma solo una funzione prestabilita e alcuni riferimenti. Il coinvolgimento dell'istituzione all'interno del processo ha permesso di ottenere il necessario appoggio per la realizzazione sottolineando quanto non vi sia solo un passaggio da bit ad atomo, ma anche un passaggio da un processo `informale' ad un contesto normativo consolidato:

6.2.2 BrickShell: sorgente progettuale Per quanto riguarda la de nizione della sorgente, all'interno di BrickShell si è scelto che la sorgente fosse un modello parametrico. Si è visto come questo tipo di strumento permetta due livelli di interazione: un primo livello, che potremmo de nire `alto', consiste nella de nizione stessa del modello; mentre un secondo livello, che potremmo de nire `basso', permette, attraverso la variazione dei parametri, di modi care non la de nizione del modello ma la sua forma nale adattandola alle proprie necessità. Questo tipo di interazione è piuttosto inusuale poiché normalmente nelle altre esperienze che

6.2.

UTILITĂ&#x20AC; DELLA SPERIMENTAZIONE

177

sono state a rontate non esiste questa di erenza, ma esiste unicamente un livello `alto'. Per poter partecipare allo sviluppo di un software bisogna saper programmare, per un progetto di Open Design bisogna saper modellare e in generale bisogna saper svolgere delle attivitĂ che l'utente medio di cilmente Ă¨ in grado di svolgere. Con il modello parametrico si riesce invece ad attuare un sistema di risultato immediato con relativa facilitĂ , che puĂ˛ spingere l'utente a comprendere meglio l'essenza della sorgente e a dotarsi degli strumenti necessari per operarvi al meglio e passare dunque da un livello `alto' a un livello `basso':

una iniziativa di architettura open source puĂ˛ dirsi tale non soltanto se la sorgente Ă¨ distribuita liberamente, ma se essa, per sua stessa natura, favorisce la modi ca e l'implementazione da parte di altri utenti, anche non esperti. Per implementare ulteriormente la fruizione della sorgente e la sua effettiva apertura si Ă¨ detto come il ricorso a sistemi modulari e dimensioni standard possa avere e etti positivi. Nel caso BrickShell non solo si Ă¨ fatto ricorso a elementi modulari (come ad esempio le centine), ma l'intero progetto delle opere provvisionali si Ă¨ basato sulla dimensione del mattone (nel caso speci co sono stati utilizzati mattoni 4,5 x 15 x 30 cm). Inoltre il modello parametrico ha permesso che questa dimensione fosse variabile.

L'utilizzo

di moduli ricorrenti ha quindi permesso di realizzare con facilitĂ un oggetto dalla forma complessa.

Se per l'Open Design questo viene fatto attraverso macchine a

controllo numerico, che permettono il controllo di tolleranze minime e la produzione anche molto limitata di pezzi senza costi particolari, per l'Architettura Open Source si sono visti diversi approcci. WikiHouse abbraccia in toto la fabbricazione digitale; mentre esperienze come Open Source Ecology utilizzano sistemi molto tradizionali come la muratura. In BrickShell si Ă¨ visto come il passaggio da informazione digitale a materia sica possa avvenire seguendo tecniche miste in mancanza di un supporto economico adeguato. Infatti ciĂ˛ non ha impedito la corretta esecuzione dell'opera poichĂŠ la centina realizzata ha permesso di realizzare una forma analoga a quella presente nel modello virtuale.

Nel passaggio da bit ad atomo non Ă¨ dunque obbligatoria la fabbricazione digitale, tuttavia devono sempre essere previsti adeguati

178

CAPITOLO 6.

APPLICAZIONE PRATICA

strumenti (tendenzialmente digitali) volti a facilitare il passaggio da bit a atomo, riducendo la possibilitĂ di errore in fase di esecuzione.

6.2.3 BrickShell: comunitĂ di pari The notion of shared authorship had important implications for the design process.

As Wojtowicz (1994) observed in a so-

mewhat similar VDS experiment conducted in 1993, designer privacy is breached [. . . ]

a designer has to give up the privacy

protecting his or her own design process and at the same time is exposed to a surrounding context [. . . ] which is constantly modi ed by other members. Surprisingly, in our experiment, the fact that no individual ownership of a design is possible seems not to pose a problem to anyone.

Perhaps this is due to the di eren-

ce in nature between the university environment and professional practice, and that the designs were abstract and of short duration. Yet the people we asked could imagine working in practice under similar conditions. Therefore, such an approach might be a strong hint to a possible future AEC working environment. The premise was that the development of a new design and collaboration environment, along with a new collaboration method, could result in 17 a breakthrough of productivity and quality. (Schmitt et al. 1999b)

In riferimento alla gestione della comunitĂ , BrickShell ha fornito alcune interessanti indicazioni. Innanzitutto Ă¨ conveniente riprendere una delle a ermazioni del capitolo precedente:

17 La nozione di autorialitĂ condivisa ha avuto importanti implicazione per il processo progettuale. Come Wojtowicz (1994) ha osservato in una esperienza simile condotta nel 1993 la privacy del progettista Ă¨ violata [...]

un progettista deve abbandonare la pri-

vacy che gli permette di proteggere il suo processo progettuale e al contempo si espone a un contesto circostante che viene continuamente modi cato dagli altri membri . Sorprendentemente, nel nostro esperimento, il fatto che non fosse possibile apporre proprietĂ intellettuali singole sui progetti non ha posto problemi a nessuno.

Probabilmente ciĂ˛ Ă¨

dovuto alla di erenza che intercorre tra la pratica professionale e l'ambiente universitario, e che i progetti erano astratti e lo sviluppo di breve durata. Eppure le persone a cui abbiamo domandato hanno risposto che lavorerebbero in simili condizioni. Pertanto un tale approccio potrebbe essere un forte indizio per un possibile sviluppo futuro dell'ambiente di lavoro AEC. La premessa era che lo sviluppo di un nuovo ambiente di progettazione, insieme a un nuovo metodo di collaborazione, potesse provocare una svolta di produttivitĂ e qualitĂ . [traduzione italiana a cura dell'autore].

6.2.

UTILITĂ&#x20AC; DELLA SPERIMENTAZIONE

179

Si puĂ˛ a ermare che la comunitĂ Ă¨ composta da tutti gli utenti che partecipano a una iniziativa di architettura open source in maniera attiva o indiretta. Per BrickShell Ă¨ avvenuto e ettivamente cosĂŹ: moltissimo Ă¨ stato svolto da utenti sviluppatori, ma molto Ă¨ stato fatto anche da tutte le altre persone coinvolte che non hanno operato direttamente sulla sorgente, ma che attraverso altre operazioni, di tipo indiretto, hanno permesso che l'intera iniziativa potesse avere luogo. Il progetto di Architettura Open Source, piuttosto che a ridurre il numero di persone coinvolte, tende infatti ad allargarlo. Questo per un semplice motivo: a ognuno viene chiesto un minimo sforzo e la totalitĂ dei minimi sforzi, se adeguatamente organizzati e sfruttati, garantirĂ una massa critica su ciente a permettere lo sviluppo del progetto. Per fare un esempio banale si puĂ˛ prendere in considerazione la comunitĂ iniziale, composta da 5 docenti (utenti promotori) e 16 studenti (utenti sviluppatori). Il rapporto Ă¨ all'incirca di uno a tre. Se consideriamo il fatto che si Ă¨ lavorato su di un unico progetto, il rapporto Ă¨ di un progetto con ventuno progettisti. Vedendo l'entitĂ del progetto, il numero di progettisti Ă¨ chiaramente spropositato ma il sistema derivato dell'Open Source permette di organizzare tanti piccoli sforzi in maniera e cace. CiĂ˛ Ă¨ stato ancora piĂš evidente nella fase di costruzione: la muratura prevede infatti che si posi un mattone dopo l'altro senza necessarie capacitĂ , la cosa importante Ă¨ seguire il pattern scelto (in questo caso non a correre ma a spina di pesce). Durante la costruzione sono state coinvolte almeno altre dieci persone oltre alla comunitĂ iniziale, coinvolgimenti di varia entitĂ come colleghi, amici e parenti.

Sono stati posati circa un

migliaio di mattoni, il che signi ca che in media ogni utente ha posato circa trenta mattoni. Trenta mattoni Ă¨ una cifra irrisoria, ma ogni singolo minimo sforzo, inquadrato in un sistema capace di valorizzarlo e di massimizzarne l'impatto, ha avuto un e etto globale di un certo rilievo. Probabilmente due muratori esperti avrebbero terminato il lavoro in meno tempo e il risultato nale sarebbe stato grosso modo lo stesso. Un altro aspetto che merita di essere a rontato Ă¨ quello legato all'autorialitĂ , la quale potrebbe essere un problema soprattutto se la comunitĂ dovesse assorbire il lavoro dei singoli senza riconoscerne gli sforzi. Ma nella pratica succede l'esatto contrario, giacchĂŠ solo attraverso il riconoscimento del lavoro del singolo la comunitĂ puĂ˛ continuare il lavoro di sviluppo. Se teniamo conto che ogni singola azione viene registrata sulla piattaforma, il problema della autorialitĂ non sussiste: ogni modi ca, ogni apporto, viene registrato sulla piattaforma.

Il lavoro di ciascun utente viene registrato all'interno della piattaforma e viene riconosciuto all'interno della comunitĂ , la quale ne valuterĂ la portata e ne garantirĂ la corretta distribuzione.

180

CAPITOLO 6.

APPLICAZIONE PRATICA

Una degli aspetti meno sviluppati in BrickShell Ă¨ stato quello relativo alla organizzazione modulare della comunitĂ . CiĂ˛ non Ă¨ stato fatto poichĂŠ si trattava di una comunitĂ giĂ piuttosto piccola e avrebbe avuto poco senso frammentarla ulteriormente. Ma nonostante ciĂ˛ si Ă¨ veri cato comunque un fenomeno interessante: nel momento in cui Ă¨ mancata la partecipazione attiva dei promotori, l'attivitĂ non Ă¨ cessata ma Ă¨ continuata secondo gli obiettivi posti in precedenza. CiĂ˛ signi ca che non Ă¨ tanto importante stabilire una divisione delle competenze a priori quanto piuttosto evidenziare e cacemente gli obiettivi da raggiungere: in base a questi la comunitĂ si auto-organizzerĂ e cacemente senza la necessitĂ di una guida in particolare.

6.2.4 BrickShell: piattaforme di supporto La piattaforma Ă¨ l'insieme di strumenti digitali che permettono alla comunitĂ di distribuire, implementare e sviluppare la sorgente. Si Ă¨ visto come la de nizione della piattaforma di BrickShell si sia basata su strumenti giĂ esistenti che, composti e ricombinati tra di loro, hanno permesso di formare un unico strumento in grado di ospitare e garantire il lavoro della comunitĂ . Utilizzare strumenti giĂ esistenti signi ca che non Ă¨ tanto la de nizione degli strumenti in quanto tali che caratterizza in positivo o in negativo la piattaforma, quanto piuttosto la de nizione degli usi che se ne deve fare. Infatti lo svolgimento di esercizi propedeutici, il ricorso alla piattaforma anche nella fase iniziale e piĂš tradizionale del workshop sono elementi che concorrono a un uso corretto della piattaforma da parte degli utenti. Ma la vera di erenza la fanno le scelte che stabiliscono le modalitĂ di lavoro collaborativo: scegliere di non seguire il modello `sta etta' ma abbracciare in pieno il modello Open Source signi ca correre il rischio di piombare nel caos, ma vuol dire anche spostare l'attenzione dallo strumento in sĂŠ (sito web, network sociale) alle modalitĂ di uso creativo e collaborativo che Ă¨ possibile innescare.

La piattaforma Ă¨ oggetto, al pari della sorgente, di progetto da parte dei promotori e per esteso della comunitĂ . La scelta di utilizzare tutti strumenti liberamente scaricabili e utilizzabili (anche se molto software utilizzato non Ă¨ open source) favorisce ovviamente il grado di apertura della sorgente. Chiunque Ă¨ in grado di scaricare il software, installarlo sul proprio computer e utilizzarlo. Inoltre la scelta di utilizzare il software parametrico permette diversi livelli di interazione, stimolando la curiositĂ degli utenti piĂš esperti ma favorendo comunque l'accesso di utenti meno esperti.

6.2.

181

UTILITĂ&#x20AC; DELLA SPERIMENTAZIONE

Non vi Ă¨ dunque un livello minimo di interazione da raggiungere, ma piĂš alta sarĂ l'interattivitĂ della piattaforma piĂš accessibile e aperta risulterĂ la sorgente.

6.2.5 BrickShell: considerazioni generali e risultati Il workshop BrickShell Ă¨ stato il banco di prova della quasi totalitĂ degli strumenti operativi dell'Architettura Open Source. Ne ha dimostrato il funzionamento in un contesto ristretto e in un periodo di tempo limitato. Attualmente Ă¨ in fase di programmazione una seconda esperienza BrickShell, i cui obiettivi sono quelli di strutturare il processo collaborativo in modo che esso possa essere ripetuto anche in altre circostanze e, dal punto di vista pratico, di minimizzare i tempi di preparazione del cantiere e di costruzione. Quello che emerge da questa esperienza Ă¨ che lo strumento dell'Architettura Open Source, se attentamente progettato, puĂ˛ essere applicato con successo. Ma come bisogna agire per utilizzare correttamente uno strumento come l'Architettura Open Source? Quando Stallman de nĂŹ il free software e la licenza copyleft che ne permetteva l'esistenza, l'Open Source non esisteva: mancava un processo de nito ed esplicito che ne permettesse l'espansione. L'apporto di Linus Torvalds (poi e cacemente sintetizzato da Raymond) Ă¨ stato fondamentale: da un lato si Ă¨ trattato di una richiesta assai banale di aiuto per e ettuare dei test di a dabilitĂ del sistema, dall'altro si Ă¨ immediatamente trasformato in una presa di coscienza degli appassionati che da amici e colleghi di Linus si sono trasformati nella prima comunitĂ open source, stabilendo le regole di un processo che ha fatto scuola. Linus ha saputo rendere esplicite delle regole che prima di allora erano solo implicite, regole legate alla tradizione hacker e dei primi programmatori. Tali regole sono state rese esplicite insieme con gli strumenti

attraverso cui metterle in atto, ad esempio sviluppando software come Git

un programma che rende possibile il lavoro di piĂš sviluppatori software su di una sola sorgente, attraverso delle regole de nite.

Proprio sulla base di

quelle regole si sono sviluppati migliaia di progetti di software open source. Wikipedia ha fatto lo stesso attraverso lo strumento del Wiki e le regole di redazione, sviluppando milioni di pagine della nota enciclopedia libera. L'Architettura Open Source dovrebbe seguire lo stesso modello. La redazione degli strumenti pratici e la loro messa in opera attraverso BrickShell ne sono un tentativo. L'Open Source Ă¨ uno strumento di sviluppo che prevede la presenza di una sorgente aperta.

Ma il metodo di sviluppo stesso Ă¨ un

metodo aperto che puĂ˛ essere utilizzato da chiunque.

18 http://git-scm.com/

182

CAPITOLO 6.

APPLICAZIONE PRATICA

Gli strumenti operativi per l'Architettura Open Source possono essere essi stessi considerati una sorgente, dai quali Ă¨ possibile sviluppare numerosi progetti, anche molto diversi tra loro.

BrickShell ne ha dimostrato il

funzionamento e sarĂ compito degli architetti, se lo vorranno e lo riterranno opportuno, utilizzarli per innescare processi di trasformazione dell'ambiente costruito collaborativi e inclusivi.

Conclusioni e sviluppi futuri

183

185

L'Architettura Open Source Ă¨ un fenomeno recente, in continua evoluzione. Si riferisce a una tradizione consolidata legata all'idea di partecipazione e democratizzazione del processo edilizio e, attraverso strumenti e tecniche proprie, realizza dei modelli di gestione e sviluppo del processo progettuale con caratteristiche speci che. Di questo fenomeno, seppur ancora in evoluzione, Ă¨ stato possibile dare una serie di de nizioni programmatiche basandosi principalmente sulla lettura dei casi studio emergenti. Ă&#x2030; stato possibile riconoscere all'Architettura Open Source alcune potenzialitĂ ed e etti, alcune dei quali non si sono ancora manifestati nella loro interezza, e che Ă¨ quindi possibile solo ipotizzare. Per quanto riguarda le potenzialitĂ e gli e etti giĂ manifestatisi, Ă¨ bene ricordarne almeno due: la prima Ă¨ relativa alla transcalaritĂ , ovvero la capacitĂ dello strumento open source di funzionare su varie scale, da quella locale a quella globale; la seconda Ă¨ legata al ruolo che il professionista Ă¨ chiamato a ricoprire in un processo aperto.

TranscalaritĂ Sono state prese in esame delle iniziative sperimentali che, proprio perchĂŠ sperimentali, presentano anche dei limiti. Nonostante questo vi sono almeno due progetti, WikiHouse e Open Source Ecology, che sembrano aver superato la fase di sviluppo iniziale e sono riuscite a consolidarsi positivamente.

Ă&#x2C6;

indubbio infatti che tutte le esperienze viste siano state salutate all'inizio della loro attivitĂ con un certo entusiasmo e positivo ottimismo. Tuttavia, alcune si sono dovute scontrare con dei limiti strutturali interni che ne hanno circoscritto fortemente l'attivitĂ , in certi casi no alla sparizione. Nel caso delle due iniziative citate sopra le cose sono andate diversamente, sia per la portata e la qualitĂ della proposta, sia per la capacitĂ di espandersi al di fuori dei con ni nazionali raggiungendo un livello di espansione globale. Infatti attraverso la creazione di sotto-comunitĂ locali si Ă¨ assistito a un vero e proprio salto di scala che no ad allora era stato immaginato da molti (nel caso di OpenSimSim con l'iniziativa OpenJapan era stato fatto anche un tentativo di messa in atto) ma non era stato ancora consolidato. Se da un lato abbiamo la conferma che Ă¨ possibile costruire e realizzare progetti a impatto globale, dall'altro l'esperienza di Brickshell conferma che anche su piccola scala l'Open Source puĂ˛ essere uno strumento molto e cace. Oltre a questa considerazione si puĂ˛ aggiungere che la varietĂ dei temi a rontati (sviluppo rurale, abitazioni peri-urbane, didattica e formazione) sono una prova dell'e cacia dell'Architettura Open Source e della sua versatilitĂ . L'architettura Open Source ha sviluppato la capacitĂ di superare la soglia del locale riuscendo ad avere un impatto globale, senza che questo ne limiti l'applicazione anche in contesti di erenti. Possiamo quindi dire

186

CONCLUSIONI E SVILUPPI FUTURI

che l'Architettura Open Source Ă¨ `glocal': in grado di gestire globalmente le istanze locali e di adattarsi a speci ci contesti attraverso il lavoro di comunitĂ transcalari di utenti.

Un nuovo ruolo per l'architetto? Un altro aspetto interessante Ă¨ legato al ruolo che il progettista si ritaglia in attivitĂ di tipo `open'. Si Ă¨ giĂ detto come venga a rontato il problema autoriale: l'autore non Ă¨ privato del suo diritto autoriale, ma entra in un sistema di erente dove l'autorialitĂ assume connotati diversi da quelli ordinari. Se la gura del promotore ricalca quella di un manager e di una guida, nel momento in cui si Ă¨ sviluppatori sembra quasi di essere al servizio delle comunitĂ senza che questo servizio venga remunerato. Nella realtĂ , proprio perchĂŠ la comunitĂ si auto-organizza, ognuno Ă¨ chiamato a ritagliarsi un ruolo secondo le sue personali abilitĂ o attitudini. Nel corso degli ultimi anni il lavoro dell'architetto ha visto emergere numerose specializzazioni (legate alla sicurezza, al risparmi energetico, alla rappresentazione etc.). Nelle comunitĂ online accade lo stesso fenomeno: ogni utente acquisisce una serie di competenze e di conoscenze speci che e la sua attivitĂ all'interno della comunitĂ nisce per acquisire una particolare connotazione. Semplicemente, non esiste piĂš un ruolo de nito a priori (attraverso l'acquisizione di un titolo professionale, ad esempio) mentre appare determinante il lavoro svolto all'interno della comunitĂ , governato dai principi di auto-organizzazione e di reputazione, e ciĂ˛ contribuisce a de nire nuovi ruoli e mandati. L'utente Ă¨ ciĂ˛ che fa, ciĂ˛ che impara a fare, ciĂ˛ che spiega e insegna agli altri; la comunitĂ diviene al contempo ente giudicante e struttura di sostegno. SarĂ compito preciso degli architetti quello di costruire un ruolo che non ne sminuisca l'attivitĂ ma che diventi pro cuo e necessario per la collettivitĂ .

Il dibattito continua Nel momento in cui questo lavoro Ă¨ in fase di completamento il dibattito sull'Architettura Open Source continua. Nel novembre 2013 Ă¨ stato lanciato da Architecture for Humanity di Denver, insieme con Open Tech Forever (un collettivo di costruttori e agricoltori precedentemente a liati a Open Source

Ecology) un concorso

aperto per la progettazione di un modulo abitativo

in blocchi di terra compressa (da costruirsi con la CEB press di OSE) per lo sviluppo di una comunitĂ agricola nei pressi di Denver. Il titolo del concorso Ă¨

19 https://github.com/AfH-Denver/Forever_Home_Design_Challenge/wiki

187

Forever Home: Open Source Building Design Challenge. La richiesta Ă¨ quella di avere il concept di una unitĂ abitativa con possibilitĂ di facili modifche da parte dell'utente, e che rispetti degli standard costruttivi anche piuttosto elevati in termini di consumo energetico e sostenibilitĂ ambientale

. Il

concorso Ă¨ terminato il 21 gennaio 2014 e ad oggi ancora non Ă¨ possibile sapere i vincitori nĂŠ tantomeno l'uso che verrĂ fatto dell'intero corpus di progetti presentati. CiĂ˛ che Ă¨ chiaro perĂ˛ Ă¨ che, seppur in via sperimentale, l'Architettura Open Source o re dei validi strumenti per favorire l'incontro tra una committenza organizzata (una comunitĂ vera e propria, non online) e il possibile progettista. La forma del concorso (basato sulla competitivitĂ ) stride con l'idea della collaborazione, ma ciĂ˛ non vuol dire che a partire da una buona idea progettuale non sia possibile in seguito sviluppare una sorgente valida. L'idea Ă¨ proprio questa: ottenere un progetto essibile che possa essere sviluppato dalla comunitĂ agricola di Denver per costruire tutte le abitazioni necessarie sui 40 acri di terreno in Colorado. Verso la ne di novembre 2013, sul website Archdaily

(una sorta di

rivista di architettura online) Ă¨ stato pubblicato un articolo dal titolo Pape-

rhouses: Architecture in Open Source 23

illustra il progetto Paperhouses

, scritto da Vanessa Quirk. L'articolo

, il quale si pone l'obiettivo di rendere di-

sponibili interi progetti di abitazioni unifamiliari, progetti giĂ sviluppati in precedenza da vari studi di architettura che partecipano all'iniziativa insieme ai promotori. The idea behind Paperhouses, founded by Joana Pacheco, is one based on collaboration: world-class architects freely provide world-class architecture to professionals and laymen, who can then download and adapt these plans as they see t (adjusting the design for program, square footage, climate, etc.) In this act, a conversation between clients, builders, and architects is born.

(Quirk 2013). Si parte non da una necessitĂ (quella del

cliente) ma da una possibile risposta (la casa disponibile su Paperhouses) per innescare un nuovo processo edilizio. Paperhouses funge cosĂŹ da repertorio pronto all'uso che ognuno degli attori puĂ˛ usare a proprio piacimento.

momento si puĂ˛ accedere unicamente alle descrizioni del progetto ma le prime piante non sono ancora disponibili, per questo motivo non Ă¨ stata inclusa

20 http://living-future.org/lbc/about 21 http://www.archdaily.com/

22 http://www.archdaily.com/452176/paperhouses-architecture-in-open-source/ 23 http://www.paperhouses.co/

24 L'idea che sta dietro a Paperhouses, fondata da Joana Pacheco, Ă¨ basata sulla collaborazione: architetti rinomati rendono disponibili gratuitamente alcune loro architetture ad altri professionisti e addetti ai lavori, i quali possono scaricare le piante e adattarle alle proprie necessitĂ (dal punto di vista funzionale, delle dimensioni, del clima). Attraverso questo processo si sviluppa un nuovo livello di dialogo tra costruttori, progettisti e clienti. [traduzione italiana a cura dell'autore].

188

CONCLUSIONI E SVILUPPI FUTURI

nei casi studio. Rimane comunque di cile pensare che una iniziativa di questo tipo possa essere considerata e ettivamente Architettura Open Source alla luce di quanto visto nora, ma la sola esistenza Ă¨ sintomatica del fatto che il dibattito sull'Architettura Open Source continua, e che gli architetti vi vedono una possibilitĂ , anche economica, di a rontare gli sviluppi della pratica professionale nel mondo contemporaneo.

Open Source e pratica professionale Oltre al salto di scala, che sta giĂ avvenendo grazie ad alcune iniziative citate, l'Architettura Open Source potrĂ consolidarsi se riuscirĂ a uscire dal limbo dell'informalitĂ per approdare a uno status di pratica comune normativamente riconosciuta.

Esattamente come il salto di scala, tale passaggio

avverrĂ grazie alla possibilitĂ di trasferire localmente le potenzialitĂ e le risorse cognitive espresse a livello globale. CiĂ˛ signi ca che saranno necessari dei traduttori in grado di trasferire in contesti speci ci istanze generali e globali. Questi saranno gli architetti, che avranno il compito, se lo vorranno e se lo riterranno giusto, di utilizzare l'Open Source come valido strumento di gestione del processo edilizio. Non sarĂ forse possibile costruire dei grattacieli open source, ma giĂ oggi la complessitĂ di alcuni interventi fa pensare che un approccio di tipo tradizionale non possa piĂš funzionare. Se e etivamente gli architetti dovranno verosimilmente confrontarsi con una maggiore domanda sociale, e con una diminuzione nella domanda di prodotti di lusso (Carpo 2009b, p. 22) sarĂ bene che si dotino degli strumenti necessari. In un sistema in cui l'utilizzo di macchinari per la fabbricazione digitale sarĂ sempre piĂš accessibile e conveniente, e in cui gli strumenti e le interfacce di connessione e di collaborazione tra utenti diversi diventeranno via via sempre piĂš e cienti, performanti e accessibili, l'Architettura Open Source sarĂ un valido strumento solo se i professionisti decideranno di adottarlo. SarĂ necessario dare piĂš importanza al processo rispetto al progetto nale, sarĂ necessario capire come trasmettere ai futuri utenti e alle amministrazioni il valore di un processo inclusivo rispetto a quello di un progetto esclusivo. Senza l'apporto dei professionisti sarĂ impensabile anche solo prevedere uno sviluppo futuro che si di erenzi dalla situazione attuale:

senza cambio di

passo si continuerĂ a proporre iniziative di Architettura Open Source che non saranno in grado di incidere sulle trasformazioni dell'ambiente costruito, ma continueranno a rimanere in uno status di `esperimento continuo'. Per nostra fortuna in paesi come gli Stati Uniti e il Regno Unito questo passaggio sarĂ forse piĂš facile, infatti non a caso Wikihouse e Open Source Ecology si stanno sviluppando con una certa fortuna proprio in quei paesi.

SarĂ necessario

189

mettere a punto degli strumenti ad hoc per fare in modo che la spinta globale di queste iniziative non si esaurisca di fronte a ostacoli burocratici locali.

Conclusioni L'Architettura Open Source sta diventando una realtĂ nel panorama architettonico contemporaneo.

Dall'inizio della rivoluzione digitale ad oggi la

pratica architettonica ha cercato di sfruttare appieno le potenzialitĂ che i nuovi strumenti informatici sono in grado di fornire.

Ora sta iniziando a

sfruttarne anche le potenzialitĂ connettive oltre a quelle computative, e tale operazione sta lentamente portando il processo architettonico da un processo chiuso quale era, popolato da poche e chiare presenze (l'architetto, il cliente e l'impresa) a un processo aperto, collettivo, plurale, in cui ruoli e mandati sono in continua fase di ride nizione e riscrittura. L'Open Source o re un modello di organizzazione del lavoro profondamente diverso da quanto eravamo abituati a vedere, radicalmente alternativo alla pratica tradizionale ma non per questo in assoluta antitesi.

Ă&#x2C6; uno

strumento potente che, se usato a dovere, puĂ˛ permettere di a rontare con relativa facilitĂ situazioni complesse. Alla luce della crisi economica che stiamo vivendo, della sempre piĂš palese scarsitĂ di risorse, della richiesta di democratizzazione dei processi di trasformazione, l'Open Source sembra in grado di o rire una modalitĂ inaspettatamente e cace di uso dei nuovi media e degli strumenti digitali. Ă&#x2C6; necessario rendersi conto che in molti altri settori l'Open Source Ă¨ stato adottato positivamente per a rontare i problemi che la complessitĂ dei rapporti contemporanei ha posto in essere. Se anche l'Architettura saprĂ farlo, avrĂ uno strumento in piĂš per a rontare con e cacia le s de progettuali che il nuovo millennio porta con sĂ¨.

Bibliogra a Abbate, J. (1999). Inventing the Internet, MIT Press. Alexander, C. (1964). Notes on the Synthesis of Form, Harvard University Press. Alexander, C. (1973). Notes on the Synthesis of Form, Harvard University Press. Alexander, C. (1979). The timeless way of building, Oxford University Press. Alexander, C., Davis, H., Martinez, J. & Corner, D. (1985). The Production

of Houses, Oxford University Press. Alexander, C., Ishikawa, S., Silverstein, M., Jacobson, M., Fiksdahl-King, I. & Angel, S. (1977). A Pattern Language, Oxford University Press. Anderson, C. (2010a). In the next industrial revolution, atoms are the new bits, Wired

18.

Anderson, C. (2010b). La coda lunga, Codice Edizioni. Arthur, W. B. (2011). La natura della tecnologia, Codice Edizioni. Avital, M. (2011). The generative bedrock of open design, in B. van Abel, R. Klaasen, L. Evers & P. Troxler (eds), Open design now, BIS. Benkler, Y. (2007). La ricchezza della rete, Universitรก Bocconi Editore. Berners-Lee, T. (1999). Weavin the Web, Harper. Berra, M. & Meo, A. R. (2001). Informatica solidale: storia e prospettive del

software libero, Bollati Boringhieri. Bocco, A. & Cavagliรก, G. (2008).

Cultura tecnologica dell'architettura,

Carocci.

191

192

BIBLIOGRAFIA

Boudon, P. (1983). Pessac di Le Corbusier, Franco Angeli. Bourriaud, N. (2002).

Postproduction, Culture as Screenplay:

How Art

Reprograms The World, Lukas & Sternberg. Cache, B. (2011). Projectiles, Architectural Association London. Calvino, I. (1993). Lezioni americane. Sei proposte per il prossimo millennio, Mondadori. Carpo, M. (2009a).

Authors, agents, agencies, and the digital public, in

M. Brizzi & P. Giaconia (eds), Visions, Image Publishing. Carpo, M. (2009b). The bubble and the blob, Lotus International

138: 19 26.

Carpo, M. (2011). The alphabet and the algorithm, The MIT Press. Castells, M. (2001). L'informazionalismo e la network society, in P. Himanen (ed.), L'etica hacker, Feltrinelli. Castells, M. (2002). Galassia Internet, Feltrinelli. Ceragioli, G. (2002).

Dare unanima al futuro:

note per un umanesimo

tecnologico, Mille. Dawkins, R. (1995). Il gene egoista, Mondadori. DeLanda, M. (2001). Open-source: A movement in search of a philosophy, Institute for Advanced Study, Princeton, New Jersey. Eco, U. (1958). Il problema dell'opera aperta, XII Congresso Internazionale

di Filoso a, Venezia. Eco, U. (1962). Opera aperta, Bompiani. Fabris, L. M. F. (2002). Metodo Segal, Libreria Clup. Floridi, L. (2012). La rivoluzione dell'informazione, Codice Edizioni. Foti, M. (2005). Tecnologie per lo sviluppo : note del gruppo Ceragioli per

una progettazione etica, Politecnico di Torino. Frazer, J. (1982).

The use of simpli ed three-dimensional computer input

devices to encourage public participation in design, in Computer-Aided

Design Conference proceedings, 03/1982. Friedman, Y. (1972). Per una architettura scienti ca, O cina Edizioni.

193

BIBLIOGRAFIA

Friedman, Y. (1975). Computer - aided parcipatory design, in N. Negroponte (ed.), Soft Architecture Machines, The MIT Press. Friedman, Y. (2000). Utopie realizzabili, Quodlibet.

Larchitettura di sopravvivenza:

Friedman, Y. (2009).

una loso a della

povertรก, Bollati Boringhieri. Gallanti, F. (2005). Elemental, aravena!, Domus

886: 34 41.

Gershenfeld, N. (2005). Fab - Dal personal computer al personal fabricator, Codice Edizioni. Goodman, N. (1976). I linguaggi dell'arte, Il Saggiatore.

http://www.apogeonline. com/2001/libri/88-503-1055-2/ebook/pdf/StoriaInternet.pdf,

Gubitosa, C. (1999). La vera,storia di internet, ultima visita novembre 2013.

Habraken, N. J. (1974). Strutture per una residenza alternativa, il Saggiatore. Habraken, N. J. (n.d.).

Molenvliet project,

html/molenvliet.htm,

http://www.habraken.com/

ultima visita novembre 2013.

Haque, U. (2002). Hardspace, softspace and the possibilities of open source architecture,

http://www.haque.co.uk/papers.php,

ultima visita

novembre 2013. Hertzberger, H. (1991). Lessons for Students in Architecture, 001 Publishers. Himanen, P. (2001). L'etica Hacker, Feltrinelli. Illich, I. (1974). La convivialitรก, Mondadori. Jenkins, H. (2007). Cultura convergente, Apogeo. Kaspori,

D. (2003).

A communism of ideas. towards an open-source

architectural practice, Archis

3: 13 17.

Kelly, K. (2011). Quello che vuole la tecnologia, Codice Edizioni. Kendall, S. (2000).

Next 21, in cib w104 open building implementation,

http://open-building.org/ob/next21.html, ultima visita novembre 2013.

194

BIBLIOGRAFIA

Kennedy, J. F. (1994). Steve wozniak: hacker and humanitarian, in G. Kawasaki (ed.), Hindsights-The Wisdom and Breakthroughs of Remarkable

People, Beyond Words. Kurzweil, R. (2008). La singolaritá é vicina, Apogeo. Kuwabara, K. (2000). Linux: A bazaar at the edge of chaos, First Monday

Larson, K., Intille, S., McLeish, T., Beaudin, J. & Williams, R. (2004). Open source building reinventing places of living, BT Technology Journal

22 No 4: 187 200. Le Corbusier, . (1953).

Le Corbusier & P. Jeanneret :

Vol

oeuvre compléte,

1934-1938, Girsberger. Lessig, L. (2006). Il futuro delle idee, Feltrinelli. Lessig, L. (2009). Remix: il futuro del copyright (e delle nuove generazioni), ETAS. Levy, P. (1996a). L'intelligenza collettiva: per un'antropologia del cyberspazio, Feltrinelli. Levy, S. (1996b).

Hacker - Gli eroi della rivoluzione informatica, ShaKe

Edizioni.

http:

Lommée, T. (2009). Introduction, in openstructures, febbraio 1997,

//openstructures.net/,

ultima visita gennaio 2014.

Lommée, T. (2011). Un esperanto per gli oggetti, Domus

648: 88 95.

Manaugh, G. (2011). Verso un'ecologia open source, Domus Marchetti,

(2006).

948: 82 87.

Arte ed estetica in Nelson Goodman,

Centro

Internazionale Studi di Estetica. McKean, J. (1986). Semi preziosi di buon senso, Spazio e Societá Menichinelli, M. (2008).

34: 18 26.

Openp2pdesign 1.1 - design for complexity, in

http://www.openp2pdesign.org/source/?download=6,

ultima visita

novembre 2013. Moglen, E. (1999). Anarchism triumphant: Free software and the death of copyright, First Monday

195

BIBLIOGRAFIA

Negroponte, N. (1974). La macchina per l'architettura, il Saggiatore. Negroponte, N. (1975). Soft Architecture Machines, The MIT Press. Negroponte, N. (1995). Essere digitali, Sperling & Kupfer. Parvin, A., Saxby, D., Cerulli, C. & Schneider, T. (2011). A right to build,

The next mass-housebuilding industry, University of She eld School of Architecture and Architecture 00:/. Pathiraja, M. (2010). Procurement strategy as means of capacity building in sri lanka: Architecture, design and labour training, Proceedings: W092

- Special Track 18th CIB World Building Congress. Digital culture in architecture: an introduction for the

Picon, A. (2010).

design professions, Birkher. Potter, N. (2002). Cos'ĂŠ un designer, Codice Edizioni. Prestinenza Puglisi, L. (2013).

Ecologia e ri uto dei valori urbani, in

http://presstletter.com/2013/ 01/6-2-6-ecologia-e-rifiuto-dei-valori-urbani/, ultima visita storia dell'architettura 1905-2008, gennaio 2014. Pugnale,

(2007).

mini-glossario,

Terminologia

speci ca,

http:

www.albertopugnale.com,

//albertopugnale.wordpress.com/2007/03/12/ i-termini-di-moda-e-i-termini-specifici-un-mini-glossario/, ultima visita gennaio 2014. Quirk,

(2013).

Paperhouses:

Architecture

open

sour-

http://www.archdaily.com/452176/ paperhouses-architecture-in-open-source/, ultima visita gennaio ce,

archdaily

2014. Ratti, C., Antonelli, P., Bly, A., Dietrich, L., Grima, J., Hill, D., Habraken, J., Haw, A., Maeda, J., Negroponte, N., Obrist, H. U., Reas, C., Santambrogio, M., Somajni, C., Sterling, B. & Shepard, M. (2011a). Editoriale: open source architecture (osarc), Domus

948: i iv.

Ratti, C., Antonelli, P., Bly, A., Dietrich, L., Grima, J., Hill, D., Habraken,

J.,

Haw,

A.,

Maeda,

J.,

Negroponte,

N.,

Obrist,

H. U.,

Reas, C., Santambrogio, M., Somajni, C., Sterling, B. & Shepard, M. (2011b).

Opensource architecture,

Opensource_Architecture,

http://en.wikipedia.org/wiki/

ultima visita novembre 2013.

196

BIBLIOGRAFIA

Raymond, E. S. (1998). La cattedrale e il bazzar, Apogeonline. Rouillard, D. (2004). Superarchitecture, le future de larchitecture 1950-1970, editions de la Villette. Salingaros, N. A. (1997).

In uence on computer science, in some no-

tes on christopher alexander,

Chris.text.html,

http://www.math.utsa.edu/~yxk833/

ultima visita novembre 2013.

Sampรณ, L. (2013). Open-source culture, Boundaries

7: 4 11.

Schmitt, G., Hirschberg, U., Kurmann, D., Kolarevic, B., Johnson, B. & Donath, D. (1999a). The 24 hour design cycle: an experiment in design collaboration over the internet., Fourth Conference on Computer-Aided

Architectural Design Research in Asia - CAADRIA, Tonji University, pp. 181 190. Schmitt, G., Hirschberg, U., Kurmann, D., Kolarevic, B., Johnson, B. & Donath, D. (1999b). An experiment in design collaboration, ACADIA

Conference Proceedings, University of Cincinnati, pp. 90 99. Senge, P. (1992). La quinta disciplina: L'arte e la pratica dell'apprendimento

organizzativo, Sperling & Kupfer. Silvestri, S. (2009). Favelas e social housing. un codice generativo per l'edilizia sociale, Bioarchitettura Sinclair,

(2006).

56: 52 59.

Open-source

architecture,

ted

talk,

//www.ted.com/talks/cameron_sinclair_on_open_source_ architecture.html, ultima visita novembre 2013. Solazzo, V. (2009).

N. john habraken:

http:

Architecture and the problem of

http://www.arc1.uniroma1.it/ saggio/Avvenimenti/NewWorld/VSolazzojohnhabraken.pdf, ultima

everyday environment, gennaio 2009, visita gennaio 2014.

Stallman, R. (2003). Software libero, pensiero libero, Stampa Alternativa. Sterling, B. (2006). La forma del futuro, Apogeo. Surowiecki, J. (2007). La saggezza della folla, Fusi orari. Sutphen, S., Ehud Sharlin, E., Watson, B. & Frazer, J. (2000). Reviving a tangible interface a ording 3d spatial interaction, In Proceedings of 11th

Western Canadian Computer Graphics Symposium.

197

BIBLIOGRAFIA

Tafuri, M. (2007). Progetto e utopia, Laterza. Tosoni, P. (1999). Derive della cultura architettonica, Celid. Tosoni, P. (2008). Il gioco paziente, Celid. Turin, D. A. (2003). Building as a process, Building Research & Information

31(2): 180187.

van Abel, B., Klaasen, R. & Evers, L. (2011).

Preface, in B. van Abel,

R. Klaasen, L. Evers & P. Troxler (eds), Open design now, BIS. Vardouli,

T. (2011a).

Geam,

giap

and

The emergence of participatory techno-utopias: yona

friedman,

openarchitecture(s),

openarchitectures.wordpress.com/2011/09/19/19/,

http://

ultima

visita

novembre 2013. T. (2011b). Prolegomena, in openarchitecture(s), http:// openarchitectures.wordpress.com/2011/09/18/prolegomena/, ul-

Vardouli,

tima visita novembre 2013. von Hippel, E. (2005). Democratizing innovation, MIT Press.

http://www.wired. com/culture/design/news/2007/03/72902?currentPage=all, ulti-

Zjawinski, S. (2007). Framing open source architecture, ma visita novembre 2013.